AI policies and consents in a company: the procedure

Definition: Preparing AI policies and consents in a company means unifying legal, operational and technical rules for the use of AI models and data: (1) classification of data and processing purposes; (2) mechanisms for consent, legal bases and retention; (3) control of vendors, security and auditability.

Last updated: 2026-02-20

Quick facts

• The most common legal risk comes from feeding personal data or trade secrets into AI tools without a clear basis and without vendor control.
• An AI policy should combine rules of use (permitted cases), data requirements (classes and prohibitions) and a procedure for approving exceptions.
• An AI activity register makes audits easier: who used the tool, for what purpose, what data was entered and how the output was secured.

The short answer

Effective AI policies and consents come from combining data protection law requirements with control of operational risks and measurable security standards for vendors and employees.

• Define roles and responsibilities: process owner, approval of use cases, legal and security oversight.
• Separate data streams: sensitive data, personal data, trade secrets, public content and synthetic data.
• Introduce evidence of compliance: logging, periodic reviews, data leak tests and an AI incident handling procedure.

Introduction

Generative tools and AI-based automation are changing the way marketing, sales, HR, IT and customer service work. Without consistent rules, the risk grows of exposing personal data, disclosing confidential content, losing rights to outputs, making a wrong decision based on a model hallucination, or breaching licence terms. The key answer is a set of documents and procedures that describe permitted uses, data classes, legal bases and vendor requirements, as well as quality and security control of outputs.

A layered approach works best: first a map of use cases and data, then an AI policy and templates for consents and clauses, and finally enforcement through training, tool configuration and audits. This order reduces the cost of corrections and makes it easier to roll out new use cases quickly.

Inventory of AI use cases and data classification

Stable compliance starts with a catalogue of AI use cases and the data classes assigned to them, because it is the data that determines legal obligations and the level of safeguards.

The inventory covers at least four areas: (1) the business process in which the AI is to operate, (2) the type of tool or model, (3) the data input and expected output, (4) how a person or a system uses the result. In practice it is important to distinguish between using AI to generate marketing content and using it to assess customer risk or analyse CVs; the same generative tools can fall under legal regimes of very different strictness.

Data classification should have simple decision thresholds: public and general data can go to cloud tools, while personal data, confidential data and data covered by an NDA require tools with processing controls, training on client data switched off and a clear retention policy. The inventory should also include derived data, for example a prompt containing a fragment of a contract, even if the data is not named explicitly.

If special categories of data or profiling with legal effects are identified, the most likely consequence is an obligation to carry out an impact assessment, stronger justifications and additional technical barriers.

Legal bases, consents and transparent communication

Consents for AI should follow from real processing purposes and data minimisation, because a badly chosen consent is weak as evidence and easy to challenge.

Designing consents and information clauses requires breaking the process down by purpose: automating replies, content analysis, generating proposals, decision support, training models or improving the service. Each purpose must have an assigned legal basis, a retention period, categories of recipients and a description of the processing logic in language the recipient can understand. If AI supports a decision rather than making it autonomously, the message should clearly distinguish a “recommendation” from a “ruling” and describe the human role in verification.

In B2B relationships, contract provisions become critical: the scope of the data processing entrustment, a ban on using data for training, retention and deletion, processing location, support in handling data subjects’ rights, and incident reporting obligations. For employees, consistency is needed with work regulations and the IT tool usage policy, because some risks come from unauthorised copying of data into public chats.

If the processing purpose is described vaguely, the consequence is a lack of accountability and difficulty demonstrating the lawfulness of AI use in an audit.

AI policy: rules of use, prohibitions and the exceptions path

An AI policy works only when it combines simple rules of use with an exceptions mechanism and operational sanctions, rather than being a mere declaration.

The document should define permitted, conditional and prohibited uses. Prohibitions often include: entering personal and confidential data into tools without approval, generating legal or medical content without a competent person, creating materials that infringe copyright, and making automated decisions without human oversight. Conditional uses require meeting criteria, for example anonymising data, using an enterprise version with training disabled, or testing answer quality on a set of control questions.

The exceptions path must name the approver, the required evidence (description of the data, purpose, retention plan, vendor, risks) and the duration of the exception. A good practice is an “AI exceptions register” with a quarterly review, so that risks do not remain without an owner. The policy should also describe a standard for writing prompts: a ban on pasting entire documents, the use of summaries, masking of identifiers, and labelling of generated content when it goes into external materials.

News from the AI market can support monitoring of changes to tool features, which makes it easier to update the list of permitted and conditional uses.

If exceptions have no expiry date, the consequence is a growth of uncontrolled integrations and an inconsistent level of data security.

Assessing AI vendors and security requirements

Safe use of AI depends on assessing vendors and configuring services, because the risk often shifts to a contractual and technical layer outside the company.

Vendor assessment covers at least: the responsibility model (controller/processor), rules on using data for training, processing location, data deletion mechanisms, encryption, access control, audit logs and access to tenant isolation features. Higher-risk uses need tests: integration vulnerabilities, resistance to prompt injection, and verification of data export from the tool. From a legal perspective, incident SLAs and the right to audit, or equivalent external reports, are critical.

In production environments, separation matters: separate accounts, an API key policy, limits on clipboard copying and role-based access control. The chain of sub-processors should also be taken into account, because an AI tool may use several intermediary services. Without these arrangements, even a correct marketing consent does not protect the data in operational practice.

API integrations are an example of an area where key control, logging and input restrictions should be written into the integration standard.

If a vendor does not provide clear retention and deletion terms, the most likely outcome is that data is kept longer than the internal policy allows.

Registers, audits and AI incident management

Accountability requires registers and audits, because without evidence it is impossible to demonstrate control over data, consents and the risk of model behaviour.

The minimum set of registers includes: a register of AI use cases, a register of vendors, a register of exceptions, and usage logs for tools that process sensitive or personal data. A register should contain: the process owner, purpose, data class, legal basis, retention period, access permissions, the output validation model and the date of the last review. Without this, it is hard to reconstruct whether a consent covered a specific purpose, or whether data ended up in a tool outside control.

An AI audit should check three layers: document compliance, configuration compliance and compliance of employees’ practices. Verifying practices includes prompt samples, the quality of anonymisation, access logs and tests of resistance to data leakage through generation. Some incidents are “silent”: pasting a file into a public chat without logs, which calls for prevention in the form of blocks and training.

Website audit is sometimes combined with a review of AI widgets and scripts, if AI supports customer service or content personalisation on the site.

If logs do not indicate the purpose and data class, an accountability test cannot tell safe use from risky use, without any increase in errors.

Which are better for creating AI policies: legal, technical or industry sources?

Legal sources are the most verifiable and carry the highest trust signal, because they derive from legislation and the positions of regulators, but they often have a general format. Technical sources are operationally precise and measurable, but need to be confirmed in configurations and audits. Industry sources help in choosing practices, but their credibility depends on the transparency of methods, conflicts of interest and whether the recommendations can be reproduced.

Sample decision matrix: data versus AI usage mode

Frequently asked questions about AI policies and consents

Is consent always needed to use AI in a company?

Consent is not the only legal basis and is not always appropriate. The choice of basis depends on the processing purpose, the role of the entity and the nature of the data, and consent is justified mainly where there is no other stable basis.

How can you tell that an AI tool should not receive personal data?

The risk grows when the vendor does not guarantee that client data is not used for training, has no clear retention rules or does not provide logs. Another signal is the inability to include the appropriate clauses or the absence of data deletion mechanisms.

What should an AI policy for employees contain?

The policy should include a catalogue of permitted tools, a list of prohibited data classes and requirements for verifying outputs. A procedure for reporting AI-related errors and incidents is also essential.

How can you limit the risk of model hallucinations in business processes?

A formal obligation of verification by a competent person and tests on a set of control questions help. In critical processes, AI must be limited to the role of a suggestion, with no automatic rulings.

Should prompt data be logged, and for how long?

Logging depends on the data class and the accountability purpose, and its scope should be minimal. Retention must follow from the policy and contracts, and sensitive data is better replaced with metadata or masking.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR) / European Union / 2016
• European Data Protection Board guidelines on transparency and consent / EDPB / years of issue depend on the version
• ISO/IEC 27001 Information security management systems / ISO / current edition
• ISO/IEC 27701 Extension for privacy information management / ISO / current edition
• Artificial Intelligence Act (AI Act) / European Union / adopted legal act

Summary

AI policies and consents require a consistent map of use cases and data classification, because legal and technical obligations depend on them. The greatest value comes from combining clear rules of use with vendor assessment and registers that make it possible to demonstrate accountability. Stability is ensured by periodic reviews, control of exceptions and tests of resistance to data leaks.