How to ask an AI model for what you need when it runs inside a business process

The most common mistake I see in AI projects is not knowing how to ask the model for things. Someone writes a vague request, gets a vague answer, and concludes that AI doesn’t work for that task. Often the model was fine. What was missing was a precise request and a way to check the answers.

I’ll use CV screening as the running example, because it’s work I’ve done for a job listings portal: a WordPress plugin connected to the listings backend, plus an AI workflow that reads and categorises CVs. The same reasoning applies to invoices, emails, forms or support requests.

In short

• Decide first what has to come out: fields, format, allowed categories, what to do when something is missing.
• Explain the context and which mistake costs more, and add a few examples.
• Ask for structured output (JSON that follows a schema).
• Test on real documents and count how often the result is right.
• Where a mistake affects people, a person who can change the outcome makes the call.
• Send the model only the data it needs, and check your GDPR obligations.

Decide what you want before you write the request

“Read this CV and tell me if it’s any good” gets a different answer every time. It doesn’t say good for what, or in what form to answer, so the model fills the gaps its own way.

Before writing the prompt, write down the output as if it were a form to fill in. It’s how I work on code too: I break the problem down and show it to the client, as a diagram or as text, before writing anything. For a CV it could look like this:

Field	Type	Allowed values
Area	one category	administration, logistics, sales, production, other
Years of experience in the area	number	whole number, or empty if it can’t be worked out
Languages listed	list	language names
Needs review	yes/no	yes if the document is ambiguous or unreadable

Categories depend on your process; what matters is that the list is closed, with one entry for cases that don’t fit.

Anthropic suggests a simple check: show the prompt to a colleague who knows nothing about the task. If they’d be confused, the model will be too (Anthropic, prompting best practices).

Give context, including what a mistake costs

Explaining why an instruction matters helps the model give more targeted answers (Anthropic). For CVs: who reads the result, what they do with it, which mistake is worse.

You classify CVs received through a job listings portal.
The result is read by a recruiter who decides whom to contact.
For them, a CV filed under the wrong area is worse than a CV
marked "needs review": when in doubt, mark it "needs review".
Use only information written in the document. If something is
missing, leave the field empty.

The last line is there to stop invented data. Anthropic’s guidance on hallucinations recommends explicitly allowing the model to say it doesn’t know (Anthropic, reduce hallucinations). OpenAI suggests stating in the prompt what to return when the input doesn’t fit the task, for example empty fields (OpenAI, structured outputs).

Show examples, including the awkward ones

Anthropic recommends 3 to 5 examples that mirror the real use case and vary enough to cover edge cases (Anthropic). OpenAI gives the same advice (OpenAI, prompt engineering).

Edge cases are the ones people forget: the CV in another language, the crooked scan, the candidate who changed sector twice, the file that isn’t a CV at all. If every example is tidy, the model calibrates on tidy. Anonymise the examples or write them from scratch; a prompt has no need for real people’s data.

Ask for structured output

A free-text answer needs someone to interpret it. Your software or plugin can read JSON with fixed fields directly:

{
  "area": "logistics",
  "years_experience": 4,
  "languages": ["Italian", "English"],
  "needs_review": false
}

Both OpenAI and Anthropic offer structured outputs: you pass a JSON schema and the response follows it, with no required fields missing (OpenAI; Anthropic, structured outputs). That guarantees the shape of the answer. The content can still be wrong, and OpenAI says so plainly: structured outputs can still contain mistakes (OpenAI). A valid “area” field can hold the wrong area.

For data extraction, ask the model to return, for each value, the sentence of the document it came from. Anthropic suggests this to make answers auditable (Anthropic, reduce hallucinations), and it saves the reviewer from hunting through the PDF.

Test on real documents and count how often it’s right

A demo on three well-chosen documents tells you little. A better routine:

1. Collect a sample of real documents, including the messy ones.
2. Have a person write the correct answer for each, in the same format as the output.
3. Run the workflow and compare field by field. With structured output, a script can do the comparison.
4. Read the errors one by one. They often share a cause, such as a badly defined category.
5. Fix the request and rerun on the same sample.

Decide in advance, with a number, what result is acceptable. Anthropic recommends specific, measurable success criteria, and counting severity too: how many errors are an inconvenience and how many cause harm (Anthropic, success criteria). One extra CV to review costs a recruiter a minute; a suitable candidate filed under the wrong area may never get a call.

When you change model, run the test again. OpenAI recommends pinning production apps to a specific model snapshot and keeping evaluations that measure prompt behaviour (OpenAI, prompt engineering).

Where a mistake affects people, a person decides

Under the GDPR, people have the right not to be subject to a decision based solely on automated processing that produces legal effects concerning them or similarly significantly affects them (GDPR, art. 22). The guidelines on automated decision-making, endorsed by the EDPB, add that human oversight has to be meaningful and carried out by someone with the authority and competence to change the decision (WP251 guidelines; EDPB).

So design the workflow to make review easy: a queue of documents marked “needs review”, the source sentence next to each value, a way to correct the classification. Someone who approves everything without looking isn’t reviewing.

Data: what you send to the model, and to whom

Go through this with whoever handles data protection in your organisation. It isn’t legal advice; these are the points to check before going live.

• Send only what’s needed. Data minimisation applies to prompts too (GDPR, art. 5(1)(c)). If classifying a CV doesn’t need the photo, date of birth or contact details, strip them before sending.
• The model provider processes data on your behalf, so you need sufficient guarantees and a contract that meets article 28 (GDPR, art. 28). For their APIs, OpenAI and Anthropic state that by default they don’t use inputs and outputs to train their models (OpenAI, data controls; Anthropic, privacy center). OpenAI keeps abuse-monitoring logs, which can include prompts and responses, for up to 30 days by default.
• Check whether you need a DPIA. A data protection impact assessment is required, among other cases, for systematic evaluation of personal aspects based on automated processing that leads to significant decisions (GDPR, art. 35(3)). National authorities publish lists of processing that needs one; in Italy, the Garante’s list (Garante, decision 467/2018, in Italian).
• Recruitment has its own rules. The AI Act lists as high-risk the AI systems used “to analyse and filter job applications, and to evaluate candidates” (AI Act, Annex III point 4). Those obligations apply from 2 December 2027, after the postponement in the AI Omnibus (Regulation (EU) 2026/1744). National labour law can add more: in Italy, since 23 October 2026, final decisions on employment relationships must be made by a person, although the decree leaves candidate search and screening outside those decisions (Legislative Decree 179/2026, art. 41, in Italian).

Where to start

1. Pick a repetitive task whose result can be called right or wrong.
2. Write the output as a table of fields, with closed categories and a “needs review” option.
3. Build a sample of real documents with the correct answers before writing the prompt.
4. Decide where a person steps in and what they need to check quickly.

Keep the workflow short. A few clear steps work better than a long chain, because every extra step multiplies the chances of error.

If you’d like to try this on one of your own processes, starting from real data, see how I work on the AI integration consulting page.