Direct answer: buying a model or outsourcing development does not outsource the responsibility. When you integrate a third-party foundation model into your own customer-service product, you remain responsible for your retrieval data, prompt design, tool integration and go-live approval; when development is outsourced, data, acceptance, go-live decisions and incident handling stay with the commissioning company; when staff use browser extensions or personal accounts for company work, that is AI use the organisation must manage. ISO/IEC 42001 asks you to write down responsibilities, evidence and exception handling for all three situations and keep them up to date.
Responsibilities in the three situations
| Situation | What you can require from suppliers or contractors | What you must do yourself | Limits that remain |
|---|---|---|---|
| Third-party model in your own product | Model version, usage restrictions, overall test results, data processing terms | Tests of your own data and prompts, go-live approval, user notices, incident handling | Where the supplier does not disclose training data, only black-box testing and contract terms can compensate |
| Outsourced development | Development documents, test reports, version records, delivery list | Acceptance criteria, data access, go-live approval, decisions on model updates and incidents | Knowledge gaps when the contractor changes staff or the contract ends |
| Staff using AI on their own | — | Allow list, exception requests, re-assessment of new uses, training | A one-off inventory never finds every use; you need ongoing discovery |
What a consultant should deliver
- A responsibility matrix: who decides, who executes and which records are kept for data, acceptance, model updates and incidents
- A list of contract clauses on information, notification and assistance duties for purchasing and outsourcing contracts
- An AI inventory that stays current, an exception request process and re-assessment when new uses are found
- An explanation of the trade-off between employee privacy and management cost (how far monitoring goes)
How to accept the work
For any purchased or outsourced AI system, the inventory leads to the owner, contract clauses, acceptance records and the latest re-assessment; when staff propose a new use, there are records of the request, assessment and approval or refusal.
What cannot be guaranteed
A consultant cannot prove what a supplier does not disclose; what can be done is to put requirements into contracts, obtain your own evidence through black-box testing, and have the responsible manager accept the residual risk in writing.
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
- How is generative AI (external LLM APIs) brought into ISO 42001? Mainly through use and third-party controls: permitted uses and prohibitions, data input rules, output review, and allocation of responsibilities and contract clauses with the model supplier; if you offer an LLM-based service externally, add life-cycle and stakeholder information. ISO 42001 implementation
- Should staff use of AI tools be banned outright? Not necessarily. An allow list plus exception requests and periodic re-assessment of new uses often works better; a total ban tends to drive use underground and lose the records. 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.