Most writing about responsible AI is addressed to organisations training their own models. Representative datasets, bias audits, model cards, fairness metrics. Important work, and irrelevant to the majority of teams shipping AI features, because they are integrating someone else's model through an API.
If that is you, the governance questions are different, smaller in number, and almost entirely about what your product does when the model is wrong. Here is the version that fits.
You inherited a model you cannot inspect
You did not choose the training data. You cannot audit it. The provider may change the model underneath you with a version bump and a changelog entry.
That rules out most classic mitigations and leaves three that still work.
Constrain the input. The narrower the task, the less room for the model to be creatively wrong. A model answering questions from your own documentation is a smaller risk surface than one answering anything.
Check the output before it acts. Validate structure, check claims against a source of truth where one exists, and refuse rather than guess. Most damage from LLM features comes from an unchecked output being treated as a decision.
Log both. Input, output, model version, timestamp. Not for analytics — for the day somebody asks why the system said what it said. Without the model version you cannot even tell whether the behaviour changed under you.
Decide where a human stays in the loop
The unglamorous heart of AI governance is a list of which decisions a model can make alone.
Suggesting a reply for a support agent to edit? Fine alone. Sending that reply? Different question. Deciding a refund, flagging fraud, screening a job application, anything touching health or credit — those want a person, and in several jurisdictions the law now agrees.
The right way to write this down is boring and effective: a table of decisions, each marked automated, reviewed, or advisory only. Product and legal own it, not engineering. When something goes wrong, this is the document that decides whether you had a process or an accident.
Bias arrives through your data, not just theirs
Even with a general model, your application supplies the retrieval corpus, the prompt, the examples, and the thresholds. All four carry assumptions.
If a support assistant is grounded in documentation written for one customer segment, it will serve that segment better. If your few-shot examples all describe one kind of case, edge cases degrade quietly. If a confidence threshold was tuned on one population, it is not calibrated for another.
The practical move is to measure quality by segment rather than in aggregate. Aggregate accuracy is the number that hides exactly the problem you are looking for.
Say when it is a machine
Disclose that a user is talking to an AI system. The EU AI Act requires it for several categories, other regimes are converging on the same expectation, and it is cheap.
It also improves the product. Users who know they are talking to a model ask differently, forgive small errors, and escalate sooner when it matters. Hiding it buys nothing and costs trust the first time somebody notices.
What the EU AI Act actually asks of an integrator
The Act sorts systems by risk. Most commercial features — support assistants, content generation, search, recommendations — sit in limited risk, where the obligations are mainly transparency: tell people they are interacting with AI, label synthetic media.
High risk is narrower and specific: employment, credit, education, essential services, safety components. If your feature touches those, the requirements are substantially heavier, and that determination should be made before the build rather than after.
The trap is assuming that using a third-party model transfers the obligation. It does not. If you deploy the system, you carry the deployer obligations regardless of who trained the model.
The short version
Four things, none of which need an ethics board.
Keep a list of which decisions the model makes alone and which a human confirms.
Log input, output and model version for long enough to answer a question about a specific case.
Measure quality by segment, not in aggregate.
Tell users when they are talking to a machine.
That covers most of the real risk in most products. The rest is genuinely a research problem, and it belongs to the people training the models.
We build LLM and AI agent integrations, and this is the part of the conversation we would rather have at the design stage. Get in touch.
