AI Data Classification Checklist for Gulf Teams
I would approve one low-risk workflow, not company-wide AI access. Before connecting it, I would set which data it may use, name its owners and require human approval for actions affecting people or sensitive records.
For a UAE or KSA team, my checks would cover:
- Data and rules: Label customer, employee and financial data; check the applicable UAE, Saudi and sector requirements.
- Tools and access: Map agents, connected systems, messaging channels, storage locations and cross-border transfers. Keep restricted data out of public AI tools.
- Controls and staff: Test permissions, logs and the kill switch; train staff and assign incident duties.
- Pilot results: Compare time, errors and cost per task in AED against a _manual baseline_. Review the tool register and access at least quarterly.
I would expand only after the pilot passes its agreed safety and performance checks.
Smart Data classification: /arckit-uae:uae-classification | ArcKit UAE overlay (experimental)
2. Set Classification Rules and Map AI Data
Before the pilot starts, put one classification policy and one AI-system register in place, based on the agreed scope and legal limits. Record each system’s owner, purpose, data categories it accesses and criticality. Cover purchased tools, embedded features, in-house builds and vendor-managed systems. [1]
Define Data Labels and Handling Rules
Set out permitted, restricted and prohibited uses. Prohibit client personal data, health records, identity documents and unpublished financials in public AI tools.
For each classification, record approved storage locations, retention periods, deletion and exit terms. State whether the provider’s terms allow company data to be used for model training. [1]
List Tools, Integrations and Data Flows
Include Odoo, SAP, Zoho, Microsoft 365 and Google Workspace wherever they form part of the workflow. Map where data is collected, sent, stored, copied or transferred. Cover prompts, outputs, messaging channels, logs, backups and cross-border data transfers.
Cross-check the register against company card records, expense claims, browser extensions and anonymous staff surveys. Review the register quarterly. [1][5]
Record Agent Access to Connected Systems
For each agent deployment, document its identity, role, credentials and source systems, plus the datasets and fields it can read or change.
Users must only see data they are already authorised to access. Match each agent’s access to the approved classification and purpose. [3][4]
3. Check Risk, Permissions and Data Residency
Turn the classification map into launch controls: who approves, who can act and where data may move. Require documented approval before production use for sensitive, high-volume or high-impact workflows. Record the business owner’s decision.
Assess Risks and Require Human Approval
Assess data sensitivity, volume, the people affected and cross-border transfers. Require documented human approval before any action affecting a person’s finances, employment, legal position or regulated records. Reviewing the output afterwards is not enough.[1]
Separate User, Agent and Administrator Roles
Give users, AI agents and administrators separate, least-privilege permissions. Before launch, test that restricted data cannot be accessed and unapproved actions are blocked.
Review privileged roles, group memberships and service account permissions at least quarterly, or immediately after staff role changes. Revoke or adjust access promptly.[5][1] Match these controls to the approved data classes in the inventory.
Verify Data Locations and Transfer Terms
Collect contractual and technical evidence showing where AI inputs, outputs, logs and backups are processed and stored, including access by subprocessors.
Have legal and privacy reviewers check applicable UAE, KSA and sector requirements, along with cross-border transfer terms. For production tools, request SOC 2 Type II and ISO/IEC 42001 evidence.
4. Control Messaging, Logs and Staff Use
Review WhatsApp Business and Telegram Workflows
Apply approved classification labels to every chat channel before any bot or staff member sends data.
Record company ownership of each business number, account, group and bot. Review WhatsApp Business and Telegram separately. Check group membership, administrator and bot permissions, forwarding, and transfers into connected systems. The approved data class determines what may pass through a group, bot or forwarded message.
Never enter client personal data, health information, identity documents, unpublished financials or credentials into public AI tools.[1]
Set Up Audit Logs and Test Controls
Once channel access is set, secure the audit trail. Use tamper-evident logs that record the channel, user or agent, data class, action, approval or rejection reason, and outcome. Store record IDs or redacted references rather than full prompt copies.
Restrict log access, set retention periods, and display timestamps in GST (UTC+4) or KSA time (UTC+3). Require human approval before outbound messages or sensitive transfers. Before launch, test the controls and keep results showing failures and how they were resolved.
Train Staff and Set Incident Procedures
Once controls are live, train staff on the workflow they will use. Tailor training by role, using approved company tools and WhatsApp Business or Telegram channels, not personal accounts. Provide guidance in Arabic and English on recognising labels, minimising prompt data and checking outputs.
Keep training acknowledgements and records of repeat training. Make incident reporting non-punitive.
Assign incident duties in advance:
- Security/CISO: Contains the incident and reviews leaks.
- Data Owner: Confirms the affected data and business impact.
- Platform Engineering: Revokes access.
- Business Owner: Remains accountable.
- Risk/Legal: Reviews notification duties under applicable UAE, KSA or free-zone rules.
Test a kill switch that revokes agent access across connected systems. Staff should report incidents immediately, not decide whether notification is required.
5. Conclusion: Approve the Pilot and Schedule Reviews
Approve one workflow only, not a company-wide rollout. Require documented sign-off from approved owners covering scope, risk, access, controls and evidence. Do not launch with unresolved high-risk issues, including uncontrolled data exposure or undocumented AI tools.[1][5]
Before launch, record a manual baseline. Then compare task time, error rate and cost per task in AED.[6] Assess safety and efficiency using these measures alongside classification-control test results. Track blocked attempts separately from incidents, and agree expansion, pause and stop criteria before live use.
Assign owners for regular access and policy reviews. Update staff training annually.[1] Reassess the approved workflow and classification map before major system, vendor or process changes, and after any UAE or KSA rule change. Expand only when the pilot meets the agreed criteria.
FAQs
How do we classify prompts containing mixed-sensitivity data?
Map the data categories, then apply the strictest controls to the entire prompt. Minimise the data used and keep categories separate. Redact sensitive information before processing. If processing requires that information to leave the region, tokenise it first. Keep models in-tenant where possible.
Screen prompts and require policy-based approvals. Send unclear cases, or those that meet sensitivity thresholds, to a named reviewer. Document the lawful basis and maintain audited logs of prompts, sensitivity assessments and human oversight.
Does local data hosting guarantee UAE or KSA compliance?
No. Local hosting is one control, not proof of compliance [1]. Organisations must still map data flows, ensure lawful processing under the UAE PDPL or local sector regulations, isolate tenants, and maintain audit trails for all AI-assisted actions [1][2].
Compliance checks must cover end-to-end data processing, including where models are trained and how data is transferred, not just where it is hosted [1][3].
How can we verify an AI provider’s deletion claims?
Product descriptions aren't proof. Require documentation, contracts and live testing to back up claims [1]. Contracts should explicitly require data erasure when the contract ends [2].
Test whether data changes or deletions made without permission are blocked or detected. Request proof of immutable audit logs, and check that revoked permissions stop further execution or data access [1]. Review the sub-processor chain and Data Processing Agreements [3].