Solutions / Risk Management and Controls
What AICOB adds that a compliance tool does not.
Most software sold into the AI assurance market is a compliance tool. It stores policies, holds a model inventory, offers a questionnaire, and produces a dashboard. That is useful. It is not a system of control.
The AI Assurance Institute's platforms are built on a process model. Control Objectives for AI Systems (AICOB) is that model. It is what turns a product from a place where information is stored into a place where work is assigned, run, reviewed and evidenced. That is the distinction. It is not a claim about features. It is a claim about the operating layer underneath every product.
A typical tool in this market is organised around artefacts. It has a library of templates, a set of checklists mapped to a regulation, a register of systems, and a report that can be exported. The user fills fields. The tool marks the fields complete. The completeness score is the product.
Three things are usually missing.
The result is a file that describes compliance. It is not a system that produces the record an authority, a notified body or a supervisor can sample when something has to be reported.
AICOB is the enterprise operating model for governing and managing AI. It turns the outcomes the governing body sets into assigned processes, controls, measures and assurance. Forty control objectives sit in five families: Evaluate, Direct and Monitor; Align, Plan and Organise; Build, Acquire and Implement; Deliver, Service and Support; and Monitor, Evaluate and Assess. The same line appears in the Institute's other products as Direct, Act, Establish, Implement, Operate and Review. The names differ. The structure does not. Governance is kept apart from management. Management then runs in a line, from intake to implementation to operation to review.
A control inside that model has four things a tick does not. A control objective says what has to be true. A trigger says when the work starts. An owner is accountable for the step. A work product is the record the step leaves. Design factors set how deep each process goes. A low-risk internal tool does not take the same process as a system that changes a customer outcome. The objectives stay the same. The practices scale.
That is why the platforms are operational, not documentary. Tasks are created, assigned and completed against processes the organisation has defined. Records are generated as the work is performed. Traceability runs from the activity to the system, to the requirement it addresses, and to the evidence that is retained. A governing body can ask what is in production, who owns it, and which controls ran. Management can ask which stage is blocked, which action is overdue, and which record is incomplete. Those are different questions. The same model answers both.
The product name changes with the topic. The method does not. Each platform is a set of processes in which controls are assigned, run and evidenced, against the regulation or standard that product is written for.
The quality management system platforms operationalise the Article 17 duty. EN 18286:2026 is the European standard written for that system. Clause 8.1 asks a provider to run its AI system through defined, documented processes at every stage of the life cycle. The platforms put that life cycle into the system itself. Each AI system is recorded once, with its intended purpose and its key characteristics. Risk, data governance, design records, technical documentation and monitoring all belong to that system. Each life cycle stage has a gate. The gate checks that the stage's records exist, that verification and validation are done, and that the right roles have signed off before the work moves on. Separation of duties is built in. Whoever prepares a record cannot approve it. Quality objectives and the risk and opportunity actions from planning are tracked work, with an owner, a due date and a link to the stage where they take effect.
That is not a document pack. Annex VI of the EU AI Act requires the provider to verify that its quality management system conforms to Article 17, that the technical documentation demonstrates the essential requirements, and that the design, development and post-market processes are consistent with that documentation. A file that describes controls that were never operated fails that test. A process that ran, with an owner and a work product, is what the test is looking for.
The AIMS platforms do the same for ISO/IEC 42001. The standard asks for an AI management system that is established, implemented, maintained and improved. It does not ask for a completed template. The platform is the operating management system: documented processes and criteria mapped to the standard, assigned owners, workflows for planning, operation and review, and records an assessor can sample. The Institute does not certify the organisation. The software makes the work visible so the decision can be made on evidence.
The GPAI Workbench is a structured register for Chapter V obligations and third-party general-purpose AI due diligence. It is integrated with the QMS for high-risk systems, and it keeps model-level and system-level obligations separate but linked. Each model record is made of structured sections, each with a status and a list of gaps that updates as the record is filled. The workbench calculates the compute indicator, the two-week notification deadline from the date the systemic-risk threshold was met, and the incident clocks from the Code of Practice. It warns where a conclusion conflicts with the evidence entered. It does not submit anything to the AI Office. It records what has to be submitted, what has been submitted, and what is overdue. A change in one place updates what is required elsewhere.
The same pattern runs through the risk and privacy platforms. The CRA platform covers the Cyber Resilience Act from scoping a product to retiring it. Each obligation has its own record type, tied to its article or annex point, and every record follows one approval lifecycle that needs a second person. Article 14 reporting runs from a recorded awareness time: 24 hours, 72 hours, and the final report. Skipped stages are refused. Overdue stages are flagged. The DORA platform holds Arts. 5 to 45 as individual obligations, linked to an operating model of processes in the same six domains, and calculates the incident clocks in RTS 2025/301. Gates and segregation-of-duties checks warn and record. They do not block, so an exception can still go through, but it is flagged and stays visible. The NIS2 platform runs a scope engine, calculates essential or important, and holds the Art. 23 clocks. An author cannot approve their own record. If an approved record is edited, it returns to draft and the approval is cleared. The DPO platform runs consent, rights, records of processing, DPIAs, breach response and retention as processes with an audit trail, and sets the Art. 33 deadline 72 hours from the base time.
In each case the platform is guiding the work against the regulation it is written for. It is not presenting a checklist of the regulation and asking the user to tick it.
Because the process model keeps the governing body and management apart, the same platform can serve both without collapsing them into one view.
The governing body evaluates, directs and monitors. It needs to see the estate, the outcomes, the exceptions and the evidence. AICOB's Evaluate, Direct and Monitor family, and the board workbenches that sit on the governance framework, give it that. Leadership, purpose and values, value generation and oversight are structured walks of one named system. They produce a board artefact, not a slide. The platform holds what is running and whether controls fired. The workbench holds how the organisation governs.
Management runs the line. Intake opens the work. Establish sets context, policy, objectives and the design of the system. Implement designs, builds, tests and deploys. Operate runs, handles incidents and attaches policy to live systems. Review samples performance, conformance and internal control, and returns findings to Direct. A material finding opens a new Act. That is how Article 17 and EN 18286 land without inventing a parallel factory, and how an AIMS, a CRA record or a DORA register is operated day to day.
Operations is the daily work inside that line. Named roles, role-based permissions, stage gates, change control, and the corrective action loop. An approved corrective action creates its own tracked record. Monitoring, incidents and nonconformities feed back into it. That is the feedback the management and the board are missing from a tool that only shows a completeness score.
The practical test of a control system is not the dashboard on a quiet day. It is the hour when a serious incident, a breach, a vulnerability or a shortcoming has to be reported, and the authority asks for the record.
A compliance tool can show that a policy existed. It cannot usually show, from the same system of record, when the organisation became aware, who owned the response, which stages were completed, which were overdue, and what evidence was locked at the time. Those are the facts the clocks depend on. Article 14 of the Cyber Resilience Act, Article 23 of NIS2, Articles 33 and 34 of the GDPR, Article 55 of the EU AI Act and the DORA incident rules all run from an awareness or classification time, and they all ask for a sequence of reports. A platform built on a process model records the awareness time, calculates the deadlines, refuses a skipped stage or flags it, and keeps the approved record. The report itself may still be sent outside the platform. The reference, the time and the evidence stay inside it.
That is the operational difference. The control and process model is what lets an organisation document the information the regulation requires, as the work is done, and have it on hand when it is needed. A template pack assembled after the event is a reconstruction. A process that ran is a record.
The distinction is not a promise of compliance or certification. The Institute does not certify an organisation and does not declare it compliant. Those decisions sit with the assessor, the notified body or the authority. The software makes the work visible so the decision can be made on evidence.
The platforms also do not replace the governing body. Software may automate inventory, policy, runtime guardrails, monitoring and evidence. It does not evaluate, direct or monitor. Accountability for the use of AI stays with the governing body. Enforcement on a platform remains a delegated control.
What they do is put a control objective, a process, an owner and a work product under every product the Institute offers, so that governance, management and operations are working from the same model, and so that the record an authority asks for is the record the process left.
