Designing an AI feature around the minimum data it needs

An AI feature does not become more useful simply because it receives the largest possible customer record. Extra detail can add exposure, distract the task and make the result harder to explain. The design question is which information changes the quality of the result in a way the user actually needs.

Start with a narrow input and test the task. Add context only when a defined failure shows why it is necessary, and examine the privacy consequence of that addition.

Write the task before assembling the prompt

Describe the output in operational terms. ‘Summarise the delivery issue for a support agent’ is clearer than ‘use AI to understand the customer’. Define the intended audience, what a useful answer contains and which decisions the feature must not make without further review.

For each proposed input field, write its contribution to that task. If nobody can explain why a full address, historical complaint or identity document changes the output, leave it out of the initial design. Use synthetic examples to explore the structure before bringing real personal data into the workflow.

The NIST Generative AI Profile identifies privacy risks involving disclosure, use and de-anonymisation, and supports examining content access throughout the AI lifecycle. It is a risk-management resource, not evidence that a particular feature or vendor has passed a privacy assessment.

Keep the legal claim precise

As of 22 October 2026, the relevant substantive DPDP duties are scheduled for 13 May 2027 under the commencement notification. The future section 4 will require an appropriate processing route for a lawful purpose. For consent-based processing, section 6(1) includes the limit to personal data necessary for the specified purpose.

Do not turn that particular wording into an inaccurate statement that every DPDP route has identical text. Choosing less data is also a practical design recommendation across many workflows, but the legal basis and exact duties still need their own assessment.

The future section 8(1) and 8(5) accountability and security framework remains relevant when an external service processes information on the organisation’s behalf. A prompt design cannot settle the provider’s role or contractual arrangements by itself.

A hypothetical delivery-summary feature

A retailer wants an assistant to summarise why an order needs attention. The first prototype receives the entire customer profile and every past conversation. The team rewrites the task and tests a smaller input: the current order status, relevant delivery event and the customer’s latest request.

Using a synthetic test set, the team compares whether the summary still identifies the next action correctly. One case needs the promised delivery window, so that field is added with a documented reason. The customer’s full purchase history and unrelated messages remain outside the input because the tested task does not need them.

The test result is described narrowly. It shows how the proposed input performs on the selected examples; it does not establish that all future cases will work or that the feature is automatically compliant. Difficult cases are routed to an appropriate reviewer.

Include retrieval and attachments

The visible prompt may be only part of what the model receives. A system can add retrieved documents, conversation history, tool results or attachments. Review those paths explicitly and apply the same task-based field assessment to them.

Check authorisation before retrieval. The OWASP Authorization Cheat Sheet recommends permission checks on every request and denying access by default. A model instruction to ignore private records is not a substitute for preventing access to records the user is not entitled to receive. Similarly, a concise final answer does not prove that the upstream system avoided unnecessary disclosure to the model service.

Measure usefulness and exposure separately

Use task criteria such as whether the summary preserves the relevant issue and supports the intended next step. Separately inspect whether prohibited information enters the input, appears in the output or is stored in logs. A single quality score should not stand in for both questions.

Record failure cases, not just average results. A small improvement in wording may not justify adding a much broader dataset. Where more context is necessary, document the trade-off and the controls around it.

Keep the approved boundary visible

Document the permitted input fields, retrieval scope, recipients, output audience and retention decisions. Revisit them when the task, model configuration or connected tools change. A new feature can quietly enlarge a previously narrow data path.

The recurring failure is allowing the available database to define the feature. Let the user’s task define the information needed, test that choice, and keep the remaining limitations visible to the people responsible for operating it.