Direct answer: the risk of an AI agent lies in what it can do, not only in what it says. An agent that queries internal data and calls the purchasing system can overstep its authority if it treats text in a document as an instruction. Governance focuses on data trust boundaries (which sources may only be data, never instructions), least privilege, human approval before high-impact actions and complete action logs. When the model discloses neither weights nor training data, you can still implement ISO/IEC 42001: obtain your own evidence through black-box validation, write information requirements into the contract, disclose the limits that cannot be removed and have the responsible manager accept the residual risk.
Validation and controls to put in place
| Area | What to do |
|---|---|
| Data trust boundary | Separate instruction sources from data sources; external documents, emails and web content must not trigger actions directly |
| Privileges | The agent gets only the privileges the task needs; purchasing and payment actions have amount and scope limits |
| Human approval | High-impact actions need human confirmation, with approver and time recorded |
| Adversarial testing | Test the agent with documents carrying embedded instructions and abnormal inputs, and feed results into risk treatment |
| Opaque models | Black-box tests, supplier information requirements, version-notification clauses, disclosure of limits |
| Division with security | Accounts, privileges, logs and incident handling are run by the security team; AI governance defines requirements and acceptance |
What a consultant should deliver
- An authorisation table for the agent and a list of high-impact actions
- Test and acceptance requirements, including adversarial scenarios, and how results enter risk treatment
- Supplier information requirements and contract clauses
- A residual-risk acceptance procedure and wording for disclosing limits
- A division-of-work table with the existing security team
How to accept the work
For any high-impact action, you can find the privilege settings, human approval records and test results; for any purchased model, you can find the contractual information clauses, black-box test records and residual-risk acceptance.
What cannot be guaranteed
Tests cannot cover every attack; a consultant cannot prove what a supplier does not disclose. What can be done is to limit privileges, keep human approval and make residual risk explicit.
Winners Consulting's approach
The following describes Winners Consulting's own approach. Please test us with the same questions above, and test other consultants too.
- Who leads: VP- and director-level consultants guide the whole engagement, without outsourcing
- Project rhythm (as listed on our service page): scope and inventory 2–4 weeks, risk and impact assessment 3–5 weeks, system build 6–10 weeks, audit and certification 4–8 weeks; organisations that already hold ISO 27001 usually reach certification in 4–6 months, from scratch about 6–9 months
- Division of roles: we build the system and the evidence chain; legal opinions come from partner lawyers; certification is carried out by a certification body accredited under ISO/IEC 42006, which we accompany but do not stand in for
- Completed work (anonymous, under a non-disclosure agreement): an industrial automation manufacturer built an AI system inventory, completed AI risk classification, established algorithm review and human oversight for high-risk uses, and obtained ISO 42001 certification
Related questions
- Can we implement ISO 42001 if the AI service we buy does not disclose its model? Yes. Obtain your own evidence through black-box validation, put information requirements in the contract, disclose the limits that cannot be removed and have the responsible manager accept them. ISO 42001 implementation
- Who is responsible for AI agent security? Accounts, privileges, logs and incident handling are run by the security team; AI governance defines the authorisation scope, human approval and acceptance requirements, and the two need a division-of-work table. AI governance consulting
Request a free mechanism diagnosis
Compliance needs all three; a consultant's value is integration
CRA, TISAX, ISO 27701 and the AI Act are not single technical problems. They are only complete when process, security technology and legal compliance all hold at the same time. Fix only one and the gaps in the other two surface during audits, incident reporting or customer due diligence, and the work has to be redone.
| Dimension | The question it answers | Typical gap when only this part is done |
|---|---|---|
| Process (management system) | Who is responsible, what is done, when, where the evidence is, how it improves | Tools are in place but nobody runs them on schedule, so there are no records at audit time |
| Security technology | How controls are designed and how their effectiveness is verified | Documents are complete but the systems do not actually do what they describe |
| Legal compliance | Which regulation applies, which role you hold, the deadlines and penalties | Controls are built against the wrong regulation or role, so obligations are not covered |
Winners' consulting team covers all three dimensions and plans regulatory scoping, process design and technical controls together, so a single body of evidence serves multiple regulations and customer requirements.