AI policy blueprint for businesses

There is no general rule requiring every business to have a document headed “AI policy”. As soon as AI is used in the business, however, existing obligations must be met in practice. Among other things, the GDPR requires a specified purpose, a legal basis, data minimisation, security and demonstrable accountability[3]. The EU AI Act requires providers and deployers to take measures to support the AI literacy of their staff and of other persons working with AI systems on their behalf[6].

A policy is one organisational building block for this. It does not prevent breaches on its own. It does, however, create a binding framework for tools, data, approvals, human oversight and reporting. This is exactly the clarity that is missing with shadow AI: employees want to get a task done but find no approved alternative and no understandable boundary.

Blanket bans are frequently circumvented in everyday work. By contrast, an overly open formulation such as “AI may be used responsibly” helps no one. The blueprint divides typical cases into three levels and links each level to a clear course of action.

The colour does not rate the product as a whole, but the specific use case. The same tool can be green for a draft based on public information and yellow or red for analysing personnel files.

The question “May personal data be used in AI?” is too broad. Before any processing, the purpose and legal basis must be established. In addition, the roles of the business and the provider, contracts, storage locations, possible transfers to third countries, deletion options and the use of inputs for the provider's own purposes must be checked. The German Data Protection Conference (DSK) also recommends clarifying whether the purpose can be achieved without personal data and whether data subject rights can be implemented in practice[1].

Even a model that is claimed to be anonymous must not be treated as anonymous without verification. The European Data Protection Board requires a case-by-case assessment. For a model to be anonymous, it must be very unlikely that individuals can be identified from the model, directly or indirectly, or that their data can be extracted through queries[5].

A policy cannot retrospectively fix an unsuitable service. Before approval, businesses should at least check whether a data processing agreement is required and available, which data the provider uses for its own purposes, whether training on inputs and outputs can be disabled, which sub-processors are involved and how deletion and access control work. For AI cloud services, the Bavarian Data Protection Authority (BayLDA) expressly names the data processing agreement, the exclusion of the provider's own purposes and trained employees as key checkpoints[7].

Technical and organisational measures are also part of the approval. The DSK cites, among other things, encryption, logging, role and permission concepts, deletion concepts and regular training. It recommends taking data protection into account from design and development through to roll-out and ongoing operation[4].

“We use provider X” is not sufficient documentation. Consumer access, the enterprise version, an embedded office feature and the API from the same vendor can have different contracts, deletion periods, administration rights, models and data flows. Approval therefore always relates to the product variant, account, feature, model and use case.

Publicly known data protection commitments do not automatically apply to every variant either. OpenAI, for example, states that by default it does not use business data from its business products and the API to train its models[13]. For its enterprise Copilots, Microsoft cites a Data Protection Addendum and no training of the foundation models on prompts, responses or Graph data, but points out that individual features, such as web search or certain sub-models, involve different data flows[14]. Google states that it does not scan private Workspace files to train its foundation models[15]. For its commercial API, Anthropic specifies a different default retention period than for products with saved chats and coding sessions[16]. These are starting points for review, not blanket approvals; contractual terms and product settings change.

A data processing agreement, or DPA for short, is generally required when the AI provider processes personal data solely on the instructions of the business. Among other things, it governs the purpose and duration, types of data, confidentiality, security, sub-processors, support with data subject rights, deletion and audit rights. If there is no DPA even though processing is carried out on the business's behalf, the service should not be used with personal data.

A DPA does not automatically make an AI use case compliant with data protection law. The business still needs a legitimate purpose and a legal basis, and must minimise data, provide information, manage risks and safeguard any transfer to a third country. If the provider uses content for its own purposes, it may itself be a controller to that extent; in that case, classification as a processor is not sufficient.

An API is a technical interface. Instead of employees working directly in a chat window, your own application sends inputs to the AI service and receives a machine-readable response. This makes it possible to filter data, restrict functions and automate checks. However, the data is still transmitted to the provider.

• Store API keys exclusively on the server side in a secrets management system—never in browser code, source code or prompts.
• Minimise or pseudonymise inputs; validate outputs before database queries, emails, payments or other actions.
• Separate access by application and environment, restrict permissions, set limits and rotate keys.
• Check retention, abuse monitoring logs, use for training, data locations and sub-processors.
• Plan for error cases, human approval and a safe way to abort from the outset.

If personal data is transferred outside the European Economic Area or can be accessed from there, a transfer mechanism is required in addition to the usual legal basis. This may be an adequacy decision, the EU-US Data Privacy Framework for certified US recipients, or appropriate safeguards such as standard contractual clauses. Additional technical measures and a documented transfer impact assessment may still be required[9].

“Servers in Germany” therefore answers only part of the question. Other relevant factors include the contractual partner, group structure, sub-processors, actual access options, encryption and key control, transparency reports and the provider's commitment to challenge disproportionate orders.

The blueprint deliberately starts from a restrictive position. Anything not approved in the tool register remains blocked. This allows a business to introduce the policy before every conceivable special case has been assessed. At the same time, the approved route must be easy to access; otherwise, new shadow AI will emerge.

A policy without technical enforcement leaves gaps. Businesses should manage approved accounts via single sign-on and multi-factor authentication, minimise local administrator rights, control AI websites and extensions on a risk basis via the browser, endpoint, DNS, proxy or CASB, use data classification and DLP, and log agent and API activity. AI must not be given permissions that the person using it does not need themselves.

Simply “disabling” PowerShell via the execution policy is not enough. Microsoft explicitly states that this setting is not a security boundary, because determined users can circumvent it[11]. If standard workstations do not need PowerShell, IT can block it via App Control for Business or comparable application control, or switch it to a constrained mode. Microsoft recommends App Control over AppLocker; rules should be tested for dependencies in audit mode before being enforced[12]. For administration, named roles, controlled scripts, separate accounts and a documented emergency procedure remain in place.

• An inventory of all AI systems, embedded features, models, agents, APIs and connectors
• A tool and use case register with status, permitted data, responsible persons and review dates
• Purpose, legal basis, data categories, data subjects and the record of processing activities
• DPA, sub-processors, transfer mechanism, transfer impact assessment and supplementary technical measures
• Data protection impact assessment, security and risk assessment, quality and bias testing
• Administrative configuration, roles, permissions, deletion periods and relevant logs
• Training plan, content, attendance, knowledge checks, and a log of changes, exceptions and incidents

All users need basic training before first use, covering functional limits, data classes, permitted tools, safe inputs, reviewing results and reporting channels. In addition, managers are trained on approvals and human oversight; IT and administration on identity, configuration, DLP, API keys, agents and incidents; development teams on secure AI development, prompt injection and output restriction; and HR, legal and data protection teams on employee data, data subject rights, impact assessments and employee co-determination. Attendance and a brief check of effectiveness are documented. Refresher training takes place at least once a year and whenever there are significant changes to the system or the policy.

The Word template is structured as an internal policy and practical guide. It contains nineteen policy areas, a conservative default configuration, provider and contract explanations, a training matrix, technical guardrails, provisions for bringing the policy into effect, a tool register, a use case review, a quick check, a provider review, a training record and a roll-out checklist. Placeholders mark every point that needs to be adapted to your organisation and processes.

The blueprint does not replace a data protection impact assessment, data processing agreements, privacy notices or technical security measures. It links these building blocks through a shared working process.

Does every business need an AI policy?
Not necessarily under that exact document title. However, businesses must meet their specific obligations regarding data protection, security, transparency, documentation and AI literacy. An internal policy makes these requirements workable for employees.

What belongs in an AI policy?
At a minimum: scope, approved tools, permitted data, human review, decisions about people, labelling, responsibilities, approvals, incidents, training and regular updates.

May personal data be entered into AI tools?
Not as a general rule. Purpose, legal basis, data minimisation, the provider's role, contracts and safeguards must fit the specific use case. Where a high risk is likely, a data protection impact assessment may be required.[3]

Is the policy sufficient for GDPR compliance?
No. Depending on the use case, further elements are needed, including the record of processing activities, contracts, privacy notices, deletion and access control concepts, and a data protection impact assessment.

Can the template be adopted without changes?
No. Tools, data classes, responsibilities, reporting channels and approvals must fit the business. Before the policy takes effect, management, data protection, IT security and, where applicable, employee representatives should be involved.

Does the CLOUD Act give US authorities access to all data in Europe?
No. It does not create unrestricted blanket access. However, a valid US order can require a provider subject to US jurisdiction to disclose data in its possession or under its control—even if the data is stored in Europe. The GDPR must also be observed.

Should coding and cowork AI be banned outright?
The blueprint initially classifies them as red. This is a safe starting point, not a fixed end result. A clearly defined use case can be approved as an exception after a documented data protection and security review.

The AI policy blueprint creates a shared standard for everyday AI use. What matters are clearly defined tools, concrete data rules, genuine human review and a functioning approval route. The editable template provides a robust starting structure for this.