AI governance for enterprises: a practical framework

What AI governance means in practice

Most organisations already have an AI principles statement. Governance is what turns those principles into decisions and controls: a list of the AI systems in use, a named owner for each, rules about what each system may do, a person who signs off on risky actions, and evidence that all of it happened.

The shift to assistants that reach your systems makes this urgent. A chatbot that answers questions can mislead; Botify can send email, update tickets or place phone calls. Governance therefore has to live partly in the product itself, as permissions and approval gates enforced before a tool runs, and not only in policy documents.

This guide is a starting framework, not legal advice. Confirm your obligations with counsel and your data protection officer.

Which laws and frameworks apply in Saudi Arabia and Jordan?

Two kinds of instruments matter. Data protection laws are binding and apply whenever AI processes personal data. AI frameworks and standards are mostly voluntary, but they give you a tested structure and a shared vocabulary with auditors and regulators.

Step 1: Inventory your AI systems and classify the risk

You cannot govern what you have not listed. NIST’s Govern function explicitly calls for mechanisms to inventory AI systems. Record every model, assistant and Botify setup in use, including tools bought by individual teams, with its purpose, owner, data it touches and systems it can change.

Then classify by what the system can do, not by how impressive the model is. For assistants, the most useful classification is per action, because one agent can hold both harmless and dangerous tools.

Step 2: Assign roles and accountability

SDAIA’s seventh principle, accountability and responsibility, holds designers, vendors, procurers, developers, owners and assessors of AI systems responsible for their effects, and calls for human oversight across the lifecycle. NIST likewise asks that roles and lines of communication for AI risk be documented and that executive leadership take responsibility for AI risk decisions. In practice, a small set of named roles covers most of this.

• Executive sponsor: owns AI risk appetite and signs off on high-risk use cases.
• AI governance group: security, legal, data protection, IT and business owners; approves new AI systems and reviews incidents.
• Data protection officer: required in defined cases under both the Saudi PDPL rules and the Jordanian law; reviews personal data flows before launch.
• System owner: accountable for one AI system, its configuration, its policies and its audit review.
• Approvers: named roles allowed to approve specific actions; never the same person as the requester for high-risk actions.
• Internal audit: tests that controls work as documented, using the audit trail rather than interviews.

Step 3: Design human oversight that actually works

Human oversight fails in two ways: nobody is asked, or everyone is asked so often that approval becomes a reflex. Put the gate on the action, not on the conversation. Reading data rarely needs a person; sending, deleting or changing records outside the platform usually does.

A good approval shows the approver the exact action and its content, such as the email text or the incident field being changed, identifies who asked and why, and can be rejected as easily as approved. The run should stay paused until an authorised person decides, and the decision should be recorded next to the action it controlled.

Review the approval log regularly. If an action is approved every time without edits, consider moving it to “allowed”; if approvers keep rejecting a certain request, fix Botify or its instructions instead of relying on people to catch it.

Step 4: Apply data protection to AI workflows

Botify moves personal data in new ways: into prompts, through model providers, into generated reports and into memory. Map each flow before launch. Saudi Arabia’s PDPL guidance stresses data minimisation and records of processing activities, and SDAIA’s rules on transfers outside the Kingdom rely on safeguards such as standard contractual clauses or binding corporate rules where the destination has not been deemed adequate.

Jordan’s law bases processing on prior consent unless an exception applies, restricts transfers to recipients offering lower protection than the law, and requires notifying affected individuals within 24 hours of a breach that would cause them serious harm, and the regulator within 72 hours. Ask your AI vendor where prompts, tool results and logs are processed, and whether credentials and outputs stay separated per tenant.

• Send the model only the fields a task needs; keep identifiers out of prompts where possible.
• Record AI processing in your records of processing activities, including model providers as processors.
• Decide what Botify may remember, for how long, and for whom.
• Apply retention and deletion rules to generated reports and transcripts, not only to source data.

Step 5: Audit, monitor and respond to incidents

An audit trail for AI should answer five questions for any run: who asked, what Botify did, with which inputs, who approved it, and what came back. Chat transcripts alone cannot answer them. NIST’s Measure and Manage functions add the operating rhythm: monitor behaviour in production, track emerging risks, and have plans to respond, recover and decommission systems safely.

Treat AI incidents like security incidents: a wrong email sent, a record changed without authority, or personal data exposed in a report. Define who triages, how to pause Botify or revoke a tool, and how the incident feeds back into policies.

How a platform can make governance enforceable

Policies written in documents only work if the software enforces them. Botify is built around that idea: every request carries the user’s identity and roles, which are checked before any tool runs; each tool is labelled read, write, destructive or external send; tenant policies allow, deny or require approval per tool and per setup; runs pause until an authorised person approves; and requests, tool calls, approvals and results are recorded in an audit trail.

Controls like these support a governance programme; they do not replace it, and using any platform does not by itself make an organisation compliant with the PDPL, Jordan’s law or any standard. The framework above, owned by named people and reviewed regularly, is what does that work.