NCA Essential Cybersecurity Controls and AI Systems: What Applies, and How

Operational control map

Use this map when translating the guide into system configuration or procedure. Replace every placeholder and add jurisdiction-specific rows before approval.

Control area	Minimum requirement	Owner	Evidence
Scope and applicability	Confirm entity, jurisdiction, activity and effective date.	[ASSIGN]	[EVIDENCE LINK]
Authoritative requirement	Link the current source from NCA, ECC.	[ASSIGN]	[EVIDENCE LINK]
Master data	Define fields, identifiers and ownership.	[ASSIGN]	[EVIDENCE LINK]
Workflow control	Record submission, approval, rejection and correction states.	[ASSIGN]	[EVIDENCE LINK]
Evidence	Retain source documents, acknowledgements and versions.	[ASSIGN]	[EVIDENCE LINK]
Exception handling	Assign escalation, target and acceptance authority.	[ASSIGN]	[EVIDENCE LINK]
Periodic review	Set an owner and regulatory review date.	[ASSIGN]	[EVIDENCE LINK]

Treat this as a maintained record. Store source publication, internal approval and next review dates, and preserve prior versions whenever a rule or workflow changes.

Shared services offers unusually clean agent economics because finance, HR, procurement and IT repeat high-volume work across business units. Rank candidates on annual volume, handling time, rework, evidence availability, tool readiness and consequence. The strongest first cases are normally read-heavy and approval-led: invoice exception analysis, supplier-pack completeness, employee-policy answers, ticket classification, reconciliation support and draft follow-up. Measure cost per correct resolution and cycle-time reduction; do not count a generated answer as completed work. Saudi deployments should also test Arabic and English requests, local identifiers, Hijri and Gregorian dates, establishment boundaries and authorised data access. Keep payments, employee-record changes and supplier approval behind deterministic validation and named human authority until production evidence supports a narrower control.

The pilot looked convincing. An agent read sample documents, answered difficult questions and completed a tool call while leaders watched. Three months later, it still serves only the project team. Security wants a data-flow map, operations cannot define an acceptable error rate, finance cannot see the unit economics, and the business owner expects technology to decide whether it is ready.

This is not primarily a model failure. A demonstration asks whether an agent can complete a curated task. Production asks whether an organisation can let it complete varied work repeatedly, detect when it is wrong, contain the consequence, recover, and remain accountable as models, data, tools and policies change.

Four fixes close that gap. They are not four new technologies. They are four pieces of operating discipline that should begin during the pilot.

Why the pilot-production gap is so persistent

Pilot incentives favour visible breadth. A team earns attention by showing several use cases, natural conversation and an end-to-end action. Production incentives favour controlled depth: one workflow, boring reliability, explicit limits and evidence over time.

The environments differ too. Pilot data is clean and selected. Credentials are powerful because integration must work quickly. Test users know what the system expects. Failures can be rerun. Production brings incomplete records, simultaneous changes, ambiguous authority, hostile content, network delays, real personal data and users who never attended the demonstration.

The word “pilot” often masks an unanswered decision. Is it research, technical feasibility, process validation or a limited production release? Each needs different evidence. A research experiment can end with learning. A production candidate needs acceptance criteria, owner, controls and a path to operation.

Teams also confuse model capability with system reliability. Benchmarks such as AgentBench and GAIA reveal useful multi-step capabilities, but an enterprise outcome depends on retrieval, identity, tool schemas, permissions, source quality and human review. A model can improve while the deployed process remains unsafe.

Fix 1: define one production-shaped outcome

The first fix is to replace a catalogue of use cases with a task contract. Name the user, trigger, eligible inputs, approved evidence, allowed actions, required output, prohibited outcomes, escalation conditions and business owner.

“Procurement copilot” is a theme. “For sourcing analysts, compare a submitted bid with the approved requirement schedule, cite omissions and draft clarification questions without scoring or contacting the bidder” is a production-shaped task.

The contract should identify the unit of work. Is one run a document, ticket, customer request, purchase-order line or completed case? Without a denominator, success cannot be measured. It should also define the system boundary. If the agent produces a recommendation and a user acts elsewhere, capture whether the recommendation was accepted and correct; otherwise the pilot measures text generation, not outcome.

Select for evidence, not theatre

A strong production candidate has meaningful volume, reviewable correctness, accessible approved data, reversible action and one owner. It should save enough time or improve enough quality to justify integration and operation.

Avoid the two extremes. A generic internal chatbot is broad but hard to evaluate. A rare, high-stakes decision may be measurable but creates too much risk and too little learning volume. Choose a repeated middle-office task where a person already checks evidence and exceptions.

Establish the baseline

Measure current volume, cycle time, waiting time, error and rework, escalation, cost and downstream outcome. Pilot teams commonly compare agent response time with human handling time while excluding document preparation, review and correction. Compare the complete process.

Define value per correct resolution. An attempted automation that requires repair is not a saving. Include platform, model, integration, reviewer, incident and support cost. Establish the minimum volume at which fixed operating cost is justified.

Define acceptance before results

Agree task-success, critical-failure, correction, latency and cost thresholds before tuning. State what happens if thresholds are missed. A pilot without a decision rule can be extended indefinitely because every result supports “more testing.”

The output of Fix 1 is a signed task contract, baseline and scale decision. That makes the business owner—not the demo team—the owner of production value.

Fix 2: engineer the boundary, not merely the prompt

Production control must exist outside natural-language instructions. A system prompt saying “do not access unrelated records” does not replace identity and authorisation.

Minimise data and authority

Authenticate users through the organisation’s identity system. Enforce their entitlements when retrieving documents and calling tools. Give the agent the narrowest data collection and smallest tool set needed for the task. Begin with read-only access, then draft actions, then approved writes where justified.

Use allow-listed tools with typed arguments. Validate identifiers, amounts, dates and states server-side. Require idempotency for actions that may retry. Separate test and production credentials. Never let model-generated text choose arbitrary endpoints, database queries or recipients.

For consequential action, place a genuine approval step. Show the approver the source facts, proposed arguments and expected effect. Record the identity, decision and execution result. Approval is not meaningful if the reviewer cannot see the evidence or cannot reasonably detect an error.

Govern the source of truth

Retrieval should use approved, owned and versioned sources. Record effective dates, business units, jurisdictions and supersession. Filter results by entitlement. Cite the source in outputs. When evidence is absent or conflicting, the agent must ask, abstain or escalate.

A shared drive is not automatically a knowledge base. Production teams need ingestion status, failed-document alerts, update ownership and tests for stale content. Source changes are releases because they can change answers without a code or model change.

Design for hostile and malformed input

Retrieved files and user messages can contain instructions intended to redirect the agent. Treat external content as data, not authority. Separate trusted system instructions from untrusted documents. Test prompt injection, data exfiltration, impersonation, malicious tool arguments and gradual manipulation across turns.

Also test mundane failures: scanned PDFs, broken tables, duplicate records, timeouts, partial API responses and concurrent updates. Most production incidents are not cinematic attacks; they are ordinary systems behaving at their edges.

Create a safe failure state

Decide what happens when identity is uncertain, evidence is missing, a tool is unavailable or monitoring fails. The answer may be read-only mode, human routing or temporary suspension. An agent should not improvise around a control it cannot reach.

The output of Fix 2 is an enforceable permission, data, action and failure boundary. Security review becomes evidence-based because the architecture expresses the claimed limitations.

Fix 3: build the evaluation loop

Most pilots have a spreadsheet of prompts. Production needs a measurement system that follows the whole task.

Create a representative offline suite

Build cases from de-identified real work. Include routine traffic, important slices, exceptions and adversarial conditions. Each case needs expected evidence, required outcome, prohibited outcome, severity and a scoring rubric. Maintain a hidden holdout so prompt authors cannot tune to every example.

Score intent, retrieval, groundedness, decision, tool selection, arguments, execution, policy compliance and final communication. Keep end-to-end task success as the primary metric. Diagnostic scores explain repair; they do not convert a materially incomplete transaction into success.

Run a critical suite on every change. Run task suites before release. Compare candidate with incumbent on identical inputs and show regressions as well as averages. A small improvement elsewhere must not offset a new severe failure.

Instrument production traces

Record task and risk class, versions of model, prompt, orchestration and knowledge, retrieved source identifiers, tool requests and results, approval, final outcome, timing, cost and correction. Minimise sensitive data and apply access and retention controls.

Do not depend on hidden reasoning as the audit trail. The operational record is the observable evidence, action and decision path. Distinguish model error from retrieval, integration, permission and data defects.

Sample and adjudicate

Use random sampling to estimate ordinary quality, risk-weighted sampling for consequential tasks, triggered sampling for corrections, retries and anomalies, and change sampling after releases. Complaints alone are biased and incomplete.

Reviewers need domain knowledge and anchored rubrics. Double-review a sample and adjudicate disagreements. Automated judges can scale triage after validation against humans, but should not decide severe privacy, financial or safety failures alone.

Close the loop

Every material production failure enters a queue. Reproduce it, classify root cause, preserve a safe test case, make the narrowest repair and run neighbouring cases to detect overfitting. Promote stable failures into regression. Monitor recurrence after release.

Evaluation is complete only when observation changes control. A dashboard that reports errors without creating owners, fixes, tests and release decisions is monitoring theatre.

The output of Fix 3 is a living relationship between production traces, human judgement, regression tests and release gates.

Fix 4: create the production operating model

A pilot has a project manager. A production agent needs enduring owners for business outcome, service operation, technical configuration, data, risk and incident response.

Name decision rights

The business owner defines acceptable outcome and approves scope. The technical owner controls releases and reliability. Source owners maintain authoritative knowledge. Security and privacy owners approve applicable controls. Operations handles queues and incidents. A risk owner accepts residual limitations where required.

Write who can increase autonomy, change a model, add a tool, onboard a user cohort, waive a gate, suspend service and restore a previous release. Ambiguity is manageable during a demo and dangerous during an incident.

Treat the entire configuration as a release

Version prompts, models, routing, tools, schemas, indexes, source collections, policies and interface confirmations. Link every evaluation and production run to a release manifest. Managed model aliases and provider changes need monitoring because behaviour can change without a repository commit.

Use progressive rollout: shadow, internal cohort, canary, wider release and only then greater autonomy. Keep the previous accepted manifest deployable. Define rollback triggers and recovery objectives.

Run incidents as operational incidents

Create severity definitions for unauthorised disclosure, wrong action, systematic misinformation, missing audit data, service degradation and near misses. Provide a route for users and reviewers to report them. Preserve evidence, contain authority, notify the right owners, correct downstream effects and perform root-cause review.

An incident may require disabling one tool rather than the whole agent. Granular controls reduce downtime. After repair, add regression tests and confirm production recovery before closure.

Own unit economics and capacity

Monitor cost per correct resolution, not tokens per call. Include review, rework, integration, observability and support. Forecast peak volume and provider limits. Identify what happens when a model endpoint, vector store or critical API is unavailable.

Measure displacement: an agent may shorten intake while increasing downstream reconciliation. Track the case to accepted completion. Benefits should appear in cycle time, error, capacity, revenue, service or risk—not just message count.

Manage change for users

Train users on the agent’s task, evidence, limits, approval responsibility and reporting route. Do not teach magical prompt formulas as a substitute for product design. Put constraints and source citations in the interface.

Tell affected teams how roles change. Review work is still work and should have capacity, service levels and quality measures. If employees believe the pilot is an undeclared performance assessment or job-removal exercise, feedback and adoption data become unreliable.

The output of Fix 4 is a service that can be released, monitored, supported, changed, financed and retired.

The four-fix production dossier

Before scale, a team should be able to produce a compact evidence pack:

Fix	Required evidence	Decision enabled
Production-shaped outcome	Task contract, owner, baseline, thresholds and value model	Is this worth operating?
Engineered boundary	Data map, source register, tool permissions, approval and failure modes	Can consequences be contained?
Evaluation loop	Versioned suite, trace coverage, sampled results, critical failures and open limitations	Is this configuration reliable enough?
Operating model	Release manifest, RACI, incident plan, rollback, support and cost	Can the organisation sustain it?

The dossier should be proportionate. A low-risk internal drafting agent does not need the same depth as a customer-facing financial agent. Every deployment does need answers in all four columns.

A recovery plan for a pilot that is already stuck

Week one: stop adding use cases. Select the one with the clearest owner and value. Write its contract and measure the current process. Identify why the last production decision could not be made.

Week two: map data, tools and identities. Remove unnecessary access. Establish approved sources, human approval and trace capture. Document failure states.

Week three: convert demonstrations and real examples into an evaluation suite. Add critical cases. Run the current configuration and classify failures by stage. Set release gates.

Week four: operate in shadow mode on real traffic. Confirm volumes, input distribution, integration reliability and reviewer capacity. Repair the system rather than curating inputs.

Week five: release to a small internal canary with daily review and clear stop triggers. Measure accepted outcomes against baseline.

Week six: make a decision. Scale one axis, repair against a dated plan, retain as research, or stop. “Continue the pilot” is not a decision unless it names the unanswered hypothesis, evidence needed and deadline.

Signals a pilot is not ready

• No person owns the business outcome or can accept the residual risk.
• The team cannot define one eligible unit of work and correct completion.
• Production data cannot be accessed under stable permissions.
• Sources have no owner, version or effective date.
• Tools use broad shared credentials or accept unvalidated arguments.
• The only evaluation is supplier-selected prompts or user sentiment.
• Critical failure classes and stop conditions are undefined.
• Runs cannot be reconstructed by complete configuration.
• Human review has no capacity, rubric or escalation authority.
• Value excludes correction, integration and operating cost.
• There is no rollback or incident route.

These are not reasons to abandon agents. They are a backlog ordered by production risk.

What not to do

Do not solve a stalled pilot by buying a more capable model before diagnosing the stage that failed. Do not widen the user group to collect “more feedback” when basic controls are missing. Do not add a committee as a substitute for naming an owner. Do not declare success from automation rate while corrections rise. Do not keep the pilot alive to protect sunk cost.

Most importantly, do not treat production as the moment experimentation ends. Production is where evaluation becomes more informative because real distributions, dependencies and outcomes appear. The goal is controlled learning with bounded consequences.

How the four fixes reinforce one another

The task contract tells security which permissions are unnecessary. The engineered boundary makes evaluation cases precise. Production traces reveal failures that improve the suite. Release gates give the operating owner a defensible decision. Unit economics reveal whether better accuracy is worth its model and review cost.

Skipping one weakens all four. An evaluation score without a task contract has no meaning. Permissions without traces cannot be demonstrated. An operating team without rollback cannot manage a regression. A strong model without ownership remains a demonstration.

The NIST AI RMF’s Govern, Map, Measure and Manage functions offer compatible language: govern responsibility; map context and impact; measure performance and risk; manage the response. The practical lesson is cyclical. No one approval makes an agent permanently safe or valuable.

Where a system helps

Pilots stall when scope is in a slide deck, access in cloud consoles, tests in notebooks, approvals in email and incidents in service tickets. CohortaOS for AI agents connects the task contract, run lineage, tool boundary, human decisions, evaluations, releases and failure actions so a pilot can accumulate production evidence instead of accumulating demonstrations.

FAQ

Why do successful AI demos fail production review?

Demos prove capability on selected inputs. Production review also needs stable data access, permissions, measurable reliability, incident response, cost, ownership and support across uncontrolled real-world conditions.

Which of the four fixes should come first?

Start with the production-shaped outcome. It determines the necessary data, actions, evaluation and owners. The four streams can then progress together.

How long should an agent pilot last?

Set an evidence target and decision date, commonly four to eight weeks for a sufficiently frequent bounded task. Rare work may need longer. Duration without a testable hypothesis is not useful.

When is an agent ready for autonomous action?

Only when the action is within risk appetite, permissions and validation are enforced, critical tests pass, production evidence is stable, rollback works and a named owner accepts the operating responsibility. Some actions should remain human-approved.

Should every agent have a separate governance committee?

No. Use a common governance framework with delegated approval by risk tier. Each agent needs named accountability and evidence; higher-risk exceptions need higher-level review.

What is the most important production metric?

Correct end-to-end resolution by task, accompanied by critical-failure counts. Cost, latency and automation yield matter only when the outcome is correct and controlled.

When should a pilot be stopped?

Stop when the task lacks value or ownership, required data cannot be governed, risk cannot be bounded, economics remain unfavourable after realistic redesign, or agreed evidence repeatedly misses the decision threshold.

Sources

• HRSD, New Phase of Nitaqat Mutawar
• SDAIA AI Ethics Principles
• NIST AI Risk Management Framework