Corporate AI policy, third-party compliance and data sovereignty

Why this matters

Lesson 32 dealt with obligations that come from outside: law, international principles and voluntary standards. This lesson deals with the rules an organisation writes for itself to meet those obligations, and with the suppliers it depends on to keep them. For most organisations this is where AI compliance is actually won or lost, because very few build their own models. They use other people's, through APIs, SaaS products and assistants embedded in tools they already own.

That makes three questions central. Which AI tools may staff use, and with what data? Can the suppliers behind those tools prove they handle the data as promised? And under whose law does the data sit once it has been sent? A support chatbot built on a hosted model, a RAG app over HR documents and a code assistant used by developers each raise all three, with different answers.

Scenario questions here typically describe an organisation that has a policy on paper and a problem in practice: staff using unapproved tools, a vendor whose terms nobody read, or personal data processed in a country the organisation did not know about. The right answer usually closes the gap between the written rule and what the systems actually do.

The lesson

Sanctioned versus unsanctioned AI, and an allow-list people can find

A sanctioned AI tool is one the organisation has assessed and approved for stated uses and data classes. An unsanctioned tool is anything else, which is where the shadow AI from lesson 31 lives. The distinction only works if the sanctioned side is real: a tool people can get, that does the job, and that they know about.

An effective policy therefore centres on an allow-list that is published where staff look for it, not buried in a policy library. Each entry states:

• The tool and the approved configuration, such as the enterprise tenant rather than the consumer app with the same name.
• Permitted uses, such as drafting, summarising, coding assistance.
• Permitted data classes, ideally mapped to the existing classification scheme: public only, internal, confidential, never regulated data.
• Conditions, such as human review before external publication or no use for decisions about individuals.
• The owner and the route for requesting a new tool, which is the approval path lesson 28 described.

The policy also needs an explicit position on unsanctioned use: what is prohibited, how it is detected, and what happens when it is found. The useful default is coaching plus a pointer to the sanctioned alternative, with technical blocking reserved for high-risk services. Enforcement uses the controls already covered: web filtering by category, cloud access security broker policies, restriction of OAuth consent to approved apps, and data-loss prevention on uploads.

Two failure patterns recur in scenarios. The first is an allow-list so short, or an approval path so slow, that staff route around it. The second is a policy that lists approved vendors but not approved configurations, so the consumer version of an approved product, with different data terms, is used in good faith.

Private versus public models, and the data each may see

The terms are used loosely, so define them by who controls the environment and the data terms.

• A public model here means a service open to anyone, typically on consumer terms, where the organisation has no contract governing retention, human review or use of inputs for training. Treat anything entered as potentially disclosed.
• A private model means one running in an environment the organisation controls or has contracted for: an enterprise tenant of a hosted model with contractual data commitments, a model in the organisation's own cloud account, or an open-weights model run on its own infrastructure.

Private is a spectrum, not a single state. An enterprise API with a no-training commitment still sends data to a third party, which still logs it for some period and may still be subject to foreign law. A self-hosted open-weights model keeps data inside the organisation but moves the burden of patching, access control, monitoring and licence compliance onto it, and its outputs are no more accurate for being local.

The policy decision is a mapping from data class to permitted deployment. A typical shape: public data may go to any sanctioned tool; internal data to enterprise tenants with contractual commitments; confidential and regulated data only to private deployments with access control, logging and the minimisation controls of lesson 14; and some data, such as authentication secrets, to no model at all. The scenario to recognise is a team proposing to send regulated records to a public model because the feature is convenient; the answer is the private deployment, or not sending the records.

Governing sensitive data that flows into AI systems

AI systems pull data in through more routes than ordinary applications, and each route needs governing.

• Prompts and uploads from users, governed by the allow-list and by data-loss prevention that recognises sensitive patterns before they leave.
• Retrieval sources in RAG applications, where indexing a document store can make every document answerable by anyone with chatbot access unless permissions travel with the content. Classification labels must follow data into indexes, as lesson 14 explained.
• Training and fine-tuning sets, which need a documented lawful basis and purpose for any personal data, provenance records, and a decision about retention, since data in the weights cannot later be reliably removed.
• Tool and connector access, where an assistant reaching mail, files or tickets inherits whatever its credentials can read.
• Logs and evaluation sets, which collect sensitive prompts and outputs as a side effect and need retention limits and access control (lesson 15).

The GDPR principles apply directly wherever personal data within its scope is involved. Data protection by design means these controls are part of the architecture from the start rather than retrofitted. Data minimisation means the AI system receives only the personal data its purpose requires, which rules out indexing a whole HR share "in case it is useful". Purpose limitation means data collected for one purpose is not quietly reused to train a model for another. High-risk processing calls for a data protection impact assessment before it starts, and decisions made solely by automated means with significant effects on people bring additional rights, including human involvement. The security professional's contribution is an accurate data-flow map: which data, from where, into which component, retained for how long, and reachable by whom. Most AI privacy findings are discovered by drawing that map.

Third-party compliance evaluations of AI vendors

Because most AI capability is bought, third-party compliance evaluation is the main way an organisation controls AI it does not run. The existing vendor risk process applies, with AI-specific questions added.

Evidence to request and read critically:

• Independent assurance reports and certifications, such as SOC 2 Type II reports, ISO/IEC 27001 certificates and, increasingly, ISO/IEC 42001 for the AI management system. Check scope: whether the specific AI service, its model hosting and the relevant regions are covered, and the period the report describes.
• Data terms: whether inputs and outputs are used for training, how long they are retained, whether staff can review them for abuse monitoring, and how deletion is confirmed.
• Sub-processors: which other companies, including the model provider behind a SaaS feature, receive the data, and where they operate.
• Model governance: how models are evaluated and red-teamed, how changes are announced, whether a version can be pinned, and what documentation such as model or system cards is published.
• Security of the AI features: defences against prompt injection and data leakage between tenants, and the vendor's vulnerability disclosure process.
• Regulatory position: whether the vendor considers itself a provider of a high-risk system or of a general-purpose model under the EU AI Act, and what information it supplies to deployers.

Contract terms turn the answers into obligations: no training on customer data without consent, retention and deletion commitments, breach and incident notification periods, notice of material model changes, data location commitments, audit or assessment rights, and allocation of liability for infringing output. Evaluation is not one-off. AI vendors change models and add features frequently, so reassessment should be triggered by material change as well as by the calendar. A scenario in which a vendor's update silently began sending data to a new sub-processor is asking for change notification in the contract and monitoring of the vendor's notices.

Data sovereignty when the model, the data and the user sit in different countries

Three terms are often blurred.

• Data residency is where data is physically stored and processed.
• Data sovereignty is the principle that data is subject to the laws of the jurisdiction where it resides, and in some cases to the laws of the country where the provider is headquartered, wherever the data sits.
• Data localisation is a legal requirement that certain data stays within a country.

AI makes these harder to pin down because one interaction touches several places. A user in Germany asks a support chatbot a question. The application runs in an EU region, but the hosted model's inference may be served from another region for capacity, prompts may be logged in the provider's home country, the vector index sits in a third location, and abuse-monitoring reviewers may work from a fourth. Each is a transfer of the data, and each may fall under a different legal regime.

The controls are architectural and contractual together:

• Map every location the data reaches, including inference, logging, fine-tuning storage, embeddings, backups and human review, not just the region shown in the console.
• Choose regional deployments and disable cross-region routing where the provider allows it, accepting the capacity trade-off.
• Use recognised transfer mechanisms for personal data leaving a jurisdiction, such as adequacy decisions or standard contractual clauses under the GDPR, with legal advice on which apply.
• Hold the keys where possible, with customer-managed keys stored in the required jurisdiction, from lesson 13, so that data held elsewhere is harder to read without the organisation's involvement.
• Consider local or sovereign deployments for data under strict localisation rules, accepting the cost and the narrower choice of models.

A scenario turning on sovereignty usually supplies the clue in the locations: a regulated public-sector body, a provider headquartered abroad, and a feature that sends data to a region nobody chose. The answer is the one that establishes where the data actually goes and constrains it, rather than one that relies on the provider's marketing description of a region.

Closing the course

This lesson brings the course back to where it started. The AI types of lesson 1 and the life cycle of lesson 6 determine what can go wrong; the threat lists of lessons 7 and 8 name it; the controls of lessons 9 to 16 contain it; the attacks of lessons 17 to 19, 23 and 24 show what happens when they are missing; the tools and automation of lessons 20 to 22 and 25 to 27 put AI to work for the defender; and the governance of lessons 28 to 33 decides who owns all of it. Across every domain the pattern is the same: find where the model touches data, people or actions, decide who is accountable for that point, and leave evidence that the control works.