AI Control Objectives (AICOB)

Control Objectives for AI Systems (AICOB) is the enterprise operating model for governing and managing artificial intelligence. It is how the organisation establishes, implements, operates, monitors, reviews, maintains and continually improves its AI ecosystem.

AICOB does not replace the definition of AI governance. It turns those outcomes into assigned processes, controls, measures and assurance.

Where AICOB sits

Three layers, one accountability model. The governing body sets outcomes. AICOB turns those outcomes into work. The AI Governance Platform applies the model to live AI uses and keeps the evidence.

• Governance Framework - outcomes against which the governing body holds management to account.
• AICOB - process model and workbench: forty control objectives in five families, mapped to law and standards.
• Governance Platform - software that registers live AI uses, attaches policy, observes or enforces controls at runtime, and retains evidence.

Select outcomes first, then the process model, then software. A platform without agreed outcomes implements activity with no test of success.

The framework AICOB puts to work

The AI governance framework is the set of outcomes against which the governing body holds management to account for the organisation's use of AI. It does not redefine governance. It states how the four outcomes are tested in operation.

The framework does not replace law, standards or internal policy. Those instruments are mapped onto AICOB and, where used, applied through the platform. The governing body's work is to evaluate, direct and monitor. Management's work is to align, plan, build, run and assure. Every material AI outcome should have both a governing-body role and a management owner.

• Ethical culture - tested by whether responsible-AI policy is approved, known and used; whether incentives and escalation support that policy; and whether exceptions and incidents are handled in line with stated values.
• Sustainable performance and value creation - tested by whether AI use is tied to purpose and strategy; whether the portfolio is known and prioritised; and whether expected value is compared with realised value, including the cost of risk, change and recovery.
• Adequate and effective control of AI resources and risks - tested by whether the governing body can see the estate of AI uses; whether risk is treated inside the organisation's business-risk profile; whether third-party and embedded AI sit in the same control system; and whether controls operate at runtime, not only as documents.
• Trust, reputation and legitimacy - tested by whether decisions leave named work products; whether accountability remains visible across legal-entity boundaries; and whether one set of processes can satisfy multiple obligations without a parallel paper framework.

An outcome is developed only when the loop is closed: policy, assigned owner, work product and review. Design factors in AICOB set how deep each process goes. The outcomes stay the same; the practices scale.

Forty control objectives in five families

For AI to function effectively, many activities need to be identified and managed. Any activity that consumes resources to turn inputs into outputs is a process, and the output of one process is often the input to the next. AICOB treats these activities as a connected system so that policy, risk controls, delivery and oversight stay aligned.

Forty AI control objectives turn stakeholder goals into assigned processes, controls, metrics and assurance. They sit in five families:

• Evaluate, Direct and Monitor (EDM) - governing-body evaluation, direction and oversight;
• Align, Plan and Organise (APO) - strategy, architecture, portfolio, people and organisation;
• Build, Acquire and Implement (BAI) - design, acquisition, build, change and deployment;
• Deliver, Service and Support (DSS) - operations, continuity, incidents and service;
• Monitor, Evaluate and Assess (MEA) - performance, conformance, internal control and assurance.

The families cascade stakeholder goals into named processes, enforceable controls, measures and independent assurance. Design factors set how much of each process is implemented, and to what depth, so the organisation does not treat "all forty at the highest maturity" as a plan.

Mapping spine

AICOB is the spine other instruments map onto, including the EU AI Act, the UK GDPR / EU GDPR, quality-management system requirements, security and service-management practice such as ISO/IEC 27001, and AI and IT governance frameworks including ISO/IEC 38500, ISO/IEC 38507 and ISO/IEC 42001-aligned elements.

A mapping is a claim only when it is explicit: one process-control activity named against a named article, clause or control. Individual maps are maintained in the workbench.

AICOB workbench

The forty processes are combined in the AICOB workbench: a single web application with group-based, role-restricted access, versioned signed archives, and user and administrator manuals. The workbench turns the forty AI control objectives into assigned practices, controls, measures and assurance. It is not forty separate applications.

The workbench is the process system. The AI governance platform is the runtime system for live AI uses. They are complementary: the workbench holds how the organisation governs; the platform holds what is running and whether controls fired.

What AICOB gives the organisation

• One accountability model. Every AI system outcome has a governing-body role (evaluate, direct, monitor) and a management owner.
• Business language for technology. Goals cascade from enterprise objectives, so a control can be shown to exist for a reason, not only that it exists.
• Complete lifecycle, not a control list. Strategy, architecture, build, run, continuity and assurance sit in one model, together with governance, portfolio, people, vendors and change.
• Tailoring instead of theatre. Depth is concentrated where risk and value are highest.
• Auditability. Practices produce named work products. Internal audit and regulators can sample a process, not a slide deck.
• Reuse across obligations. One process-control activity can support more than one instrument when the mapping is explicit.
• A stable spine when technology changes. Agents and models change quickly; benefits, risk, change, incidents and performance do not.

Software may automate inventory, policy, runtime guardrails, monitoring and evidence. It does not replace the governing body's duty to evaluate, direct and monitor.