Working with an AI Engineering team when you are not an engineer

What you do not have to do

Let us remove some unnecessary pressure first. You do not have to pick a model, arbitrate between two retrieval approaches, assess an architecture or judge implementation quality. Those decisions belong to the team, and taking them over creates the worst outcome: a solution imposed from outside for which you remain accountable to the business.

On the other hand, nobody will do your part: defining the problem, saying what is acceptable, bringing real cases and settling business trade-offs. An AI Engineering team deprived of those inputs invents them — and invents them badly, not out of incompetence, but because it has no access to the field.

The right boundary is not "business on one side, technology on the other". It is: you describe what must be true, the team decides how to make it true, and you discuss together what it costs.

Bring a problem, not a solution

Requests almost always arrive already dressed as solutions. They travel through the organisation in technical form, often borrowed from a demo seen elsewhere, and they close the discussion before it starts.

The second version requires no technical skill. Yet it contains everything the team needs: the need, the users, the nature of the data, the constraints, the risks and the beginning of a success criterion. It also leaves open the possibility that something far simpler than an agent solves the problem.

Reframing a request that already arrived as a solution

When the request arrives in technical form — and it will — reframing takes six questions, asked without hostility: which human work are we trying to lighten, who does it today, on which data, which actions would the system be allowed to take, what would be serious, and how will we know it works? Those are the six angles the team will need anyway.

Describe the expected behaviour

On an AI system, a specification cannot enumerate every possible input. It describes behaviour: what the system does normally, what it does when unsure, what it never does. That description need not be technical, but it must be observable — someone should be able to look at an output and say whether it respects the rule.

• Scope: which cases are handled, which are explicitly excluded, and whether the exclusion is visible to the user.
• Nominal behaviour: what the system produces, in what format, with what references or justification.
• Behaviour under doubt: abstain, offer a partial answer, ask for clarification, escalate to a human.
• Hard prohibitions: what the system must never produce, under any circumstances.
• Human control: at which point of the journey, by whom, and with what information to decide.

Acceptable and unacceptable errors

This is the most useful contribution a business profile makes, and the most frequently skipped. No AI system is error-free, so the question is not "how many errors" but "which ones". A technical team cannot settle that for you: it belongs to business risk, contracts, customer relationships and sometimes regulation.

• An acceptable error: an incomplete answer the user spots immediately and fixes at no cost.
• A costly error: a plausible but wrong answer the user cannot distinguish from a correct one.
• An unacceptable error: a commitment, a promise, exposed personal data, a decision presented as approved when it is not.
• A deliberate asymmetry: it is often preferable for the system to stay silent ten times wrongly than to assert once wrongly.

Naming those three categories immediately reshapes the technical conversation: it drives guardrails, thresholds, the placement of human control and how the system behaves when unsure.

Bring real cases, including the awkward ones

A set of real cases is the most valuable thing a business profile brings, and often the only thing the team cannot produce alone. Twenty field cases beat a twenty-page specification, because they carry ambiguities nobody would have thought to write down.

• Ordinary cases, representative of daily volume.
• Awkward cases: badly phrased requests, missing information, several questions bundled into one.
• Edge cases: rare but high-stakes situations where an error is expensive.
• Out-of-scope cases, to check the system refuses them cleanly.
• For each case, what a good human answer would have been — that reference is what makes evaluation possible.

These cases must be anonymised and comply with the organisation's data handling rules. Deal with that at the start, not when the team is waiting for the test set.

Contribute to defining the evaluation

Evaluation is where business and engineering meet. The team knows how to measure, compare two versions and automate checks. What it does not know is what counts: which gap is tolerable, which dimension outranks the others, which threshold authorises a release.

• Say what "good answer" means in your domain, on specific examples rather than in the abstract.
• Rank the dimensions: accuracy, completeness, tone, format, speed — they cannot all be top priority.
• Set thresholds with the team: what triggers a release, what triggers a rollback.
• Accept reviewing outputs: a regular human review of a sample stays the most reliable measure early on.
• Plan for repetition: evaluation is not a milestone, it is a mechanism replayed on every change.

Prototype and production: two different conversations

Much of the tension comes from a misunderstanding about the status of what is being shown. A successful demo proves a behaviour is possible on chosen cases. It says nothing about stability on unchosen ones, cost at real volume, behaviour when a dependency fails, or the maintenance burden.

A product or project profile's job is to name that difference while it is still free — before the demo has been shown to a committee that will read it as a delivery. The question to ask is not "when is it ready?" but "what is missing between what you are showing and something our users can use without us?".

Understand data dependencies without becoming a Data Engineer

The quality of an AI system depends first on what it can reach. You do not need to understand the pipelines, but a few questions are squarely business questions that nobody else can answer.

• Which sources are needed, who owns them, and under what conditions they may be used.
• How often they change, and what becomes of an answer built on an outdated version.
• Who is allowed to see what: an assistant must never widen its user's permissions.
• What is missing: the knowledge people hold but that is written nowhere.
• What is retained, for how long, and what may be exposed to a third party.

Discuss latency, cost and quality as a product trade-off

The three are linked: raising quality often lengthens response time and increases cost per use. A technical team can describe the options; it cannot decide alone which one serves users best. That is a product trade-off, and naming it as such prevents it from being settled by default.

• Latency: what delay stays acceptable in the real journey — not on average, but in the common worst case.
• Cost: what cost per use stays sustainable if volume doubles, and who watches that number.
• Quality: from which level the service becomes useful, and beyond which level extra effort adds nothing for the user.
• What you agree to sacrifice first if the three cannot be reached together.

What belongs to product, what belongs to engineering

An explicit boundary removes most friction. It deserves to be set once, at the start, rather than renegotiated at every disagreement.

• Product: the problem, the users, the scope, the expected behaviour, the prohibitions, the priorities, acceptance thresholds, the placement of human control.
• Engineering: architecture, component choices, retrieval strategy, evaluation implementation, performance, operations.
• Jointly: what gets measured, the quality / latency / cost trade-off, the release slicing, the go-live decision.
• Nobody: whatever is written nowhere ends up settled implicitly, usually at the worst moment.

Document decisions, not discussions

On an AI project, system behaviour is the accumulation of small decisions: a scope narrowed here, a threshold raised there, a case dropped because it was too rare. Six weeks later nobody remembers why, and the same question returns unchanged.

A short trace is enough: the decision, the date, the reason, and what you agreed to give up. That document is not administrative overhead — it is what lets you answer a user who challenges a behaviour, and what prevents relitigating the same debate three times.

Questions worth asking in review

A good review question is not about implementation. It is about what has been decided implicitly and what will happen when the situation is not ideal.

• On which cases did you see behaviour degrade?
• What does the system do when the information does not exist in the sources?
• What changed since the last version, and how do we know it is better?
• Which cases did we decide not to handle, and is that visible to the user?
• What worries you most if we put this in front of real users?
• What do you need from our side to move forward?
• What depends on an external provider, and what happens if they change it?

The last question — "what do you need from our side?" — moves the most. It surfaces whatever the team has been waiting for over three weeks without formally asking.

Avoiding technical micro-management

The line is easy to state: questioning a result is legitimate, prescribing an implementation is not. Asking why the system answers that way on three specific cases is a contribution; suggesting a model change, a prompt tweak or an extra technical step is an intrusion, even with good intentions.

One case still justifies insisting: when you do not understand a behaviour you will be accountable for. Asking for a further explanation is not micro-management then, it is a condition for doing your job. The phrasing that works is direct: "I need to be able to explain this behaviour to a user; can you restate it in terms I can reuse?".

An AI Engineering team works better with a product counterpart who asks hard questions about behaviour than with a silent one who discovers the result in production. Collaboration does not require engineering skills; it requires precision, real cases and a clear boundary.

• AI Engineering
• Evaluation
• AI Product