AI tools Compliance
What you should really check before implementation
AI tools are live in many companies faster than any other IT innovation in recent years. One click in the browser, an add-in in Office, a new SaaS for the team and you’re up and running.
But the real questions rarely come before the go-live, but afterwards. Where does our data really end up? Who has access and how do we prevent data leakage via prompts and outputs? What does the contract say if something goes wrong? What does data protection expect? What evidence do we need if security or auditing asks for it? And how do we properly classify the use in the EU AI Act?
This article is therefore not a policy paper on AI tools and compliance. It is a pragmatic audit trail that you as a decision-maker can use to clarify:in a short time: Are we allowed to do that? Can we operate it safely and in an auditable manner? And what do we need to be able to prove before we scale the tool in the company?
5 key takeaways
- AI tools Compliance does not check “the tool”, but its use. The decisive factors are the specific use case, the processes involved and which data is actually processed.
- The quickest way to safety is a clear audit trail instead of individual discussions. Use Case & Risk → Data Protection → Security → Provider Verifications → Contract → Quality/Safety → Operation/Governance.
- GDPR usually fails because of data flows, not because of paragraphs:if nobody can explain what data goes where (and who has access), DPIA/contracts and controls are automatically shaky.
- Security is a minimum standard at GenAI, not a “nice-to-have”. access (SSO/MFA/roles), DLP/masking, logging/audit trail, secure integrations and exit/portability determine whether you can operate the tool responsibly.
- Compliance is achieved on the store floor. Models and features change. Without RACI, an audit trail, a few good KPIs and a change/incident process, “once tested” quickly becomes worthless.
AI tools compliance in one sentence: what you really need to check
The short answer: You are not testing “the tool”, but the specific usealong a clear path: Classify use case & risk → Clarify data protection → Ensure security → Evaluate provider evidence → Draw up a clean contract → Test quality of results & safety → Firmly anchor operation and governance.
The reason is simple: AI tools rarely fail because of the feature set. They fail because one component is missing and then the benefit is lost. Without proper classification, you end up in an application that is not viable from a regulatory perspective. Without data protection and security, you risk data leakage and loss of trust. Without a contract and evidence, the first audit will be unpleasant. And without tests and an operating concept, “helps the team” quickly becomes “produces errors and nobody notices in time”.
Key point for decision-makers: Compliance here is not bureaucracy, but operational security.
Step 1 - Classify: AI tools & AI act risk
It starts with a question that sounds banal, but is almost always the point at which projects later come to a head: Which process does the tool actually influence? A writing assistant that smoothes internal texts is a different world in terms of risk and obligations than a system that pre-sorts applications, evaluates access or assesses credit risks.
The consequence is not “more paper”, but more clarity. You need a brief use case classification that sets out three things: Purpose, Groups of people affected (if people are affected) and Data categories. This allows you to answer the key questions early on: Is it enough to regulate transparency properly? Do you need to seriously examine high-risk obligations? Or are you operating in an area that is simply not sustainable in this form?
This is the moment when you gain time as a decision-maker: You prevent a tool from “accidentally” slipping into a sensitive process – and later forcing compliance, IT and the specialist department into an expensive backwards maneuver.
Request an audit trail workshop
Step 2 - GDPR: Data flows, roles, legal basis
Many AI projects fail not because of “the GDPR”, but because of something much more commonplace: Nobody can clearly explain which data flows where. GenAI makes it extremely easy to drag personal data along on the side. Not out of ill will, but out of habit.
A support ticket is summarized, an email is reworded, conversation notes end up in the prompt, a screenshot is attached. Personal data is already being processed without anyone having named it as such.
You need two clarifications so that you are not steering in the fog. Early on, before the tool is “factually set”.
- What roles do you and the provider have? Are you the controller and the provider the processor? Or are you jointly responsible (depending on the setup)? This is not a formality, but determines which contracts, obligations and evidence are appropriate.
- Which legal basis and which protective measures are appropriate for precisely this use?“We only use it internally” is no substitute for a legal basis. And “the provider is in the cloud” is not a protective measure. The decisive factor is the combination of purpose, data categories, recipients, storage/training logic and access.
When is a DSFA/DPIA realistically necessary?
The short answer: If the processing is expected to be High risk for the people affected. In the AI context, typical triggers are: Profiling/Scoring, sensitive data, large amounts of data, or processes that are difficult to explain and noticeable consequences for people (for example HR decisions).
If you answer this question early on, you avoid the classic situation: the tool is already in use, everyone has gotten used to it and suddenly a DSFA becomes a retrospective emergency stop. This is not only expensive. It costs internal trust in the whole AI topic.
Step 3 - Security: minimum standard for AI tools
GenAI is not just “an app”. It is a
In practice, eight topics have proven their worth, which you should clarify before going live. The decisive factor is not so much the length of the list, but the question: Can you prove and control this later – or do you simply hope that nothing happens?
- Access and identity.SSO, MFA and a clear role model are the basis for ensuring that “team tools” do not become uncontrolled shadow IT.
- DLP, masking or clear rules on which data is allowed in prompts and files are not “nice to have” with GenAI, but damage limitation.
- Encryption and key management:Not just “encrypted?”, but: Who controls keys, how are they managed, what options are there for particularly critical data?
- Logging and audit trail:who used what, what actions were carried out, what was shared – so that you are not blind in the event of an audit or incident.
- Multi-tenantis not automatically bad, but you need to understand how isolation and access are really implemented and where data is processed.
- Secure integrations: GenAI often becomes dangerous not in the chat window, but in the connection to CRM, ticket systems or email: Then “texts” become real process data.
- Vulnerability and patch processes:How quickly does the provider react, how are gaps communicated, what is your own process for updates and releases?
- Exit and portability:what happens if you terminate your contract? How do you access data, how is it deleted, how do you avoid lock-in?
The point is not to build “perfect security” in two weeks. The point is: you want to be able to control what is allowed in, who uses it, what comes out and what happens in an emergency. That’s the difference between a tool that feels good and a tool that can be operated securely.
Prepare go-live safely
Step 4 - Vendor due diligence: Evidence instead of slides
Providers like to say that they are “secure” and “compliant”. That is understandable. Marketing has to live somehow. But there is only one question that counts for your due diligence: How do we determine this? Not in the sense of mistrust, but in the sense of operational reality: if something happens or someone checks, you need reliable answers.
A consistent evidence mindset helps here. They don’t look at promises, but at the evidence and the mechanics behind them:
- Which certifications are available and for which scope?
- What audit reports or independent audits are available?
- Which sub-processors are involved, how are changes communicated?
- How does incident response work in practice, including reporting deadlines and responsibilities?
- Who has support access on the provider side and how is this controlled and logged?
- And very importantly, what does change management look like when models, features or data flows evolve?
What ISO 27001/27701/42001 can and cannot do as a signal
ISO certificates are strong signals, because they show: There is a management system behind it, not just technology, but processes, responsibilities and regular checks. ISO 27001 primarily addresses information security, 27701 supplements privacy management and 42001 is aimed at an AI management system.
The catch is relevant: An ISO certificate is is not a free pass. It does not replace your use case review, and it does not automatically answer whether exactly the product you want to purchase is properly covered in exactly your operating mode. The decisive factor is whether the specific tool and the relevant operation (e.g. region, client model, integrations, data types) in the Scope and whether the controls match your risk profile.
In short: certificates are a good starting point. The actual due diligence is the translation to your application: Does this match our data, our process and our audit level – or does it only look good on paper?
Clarify security & data protection
Step 5 - Contract & law: what really counts in the small print
Contracts are often the part that you prefer to “somehow get through” so that the tool can finally go live. However, this is exactly where the risks lie, which later cost real money and nerves because they escalate not technically, but legally and organizationally:
Who is liable for errors? What happens to your data (storage, processing, deletion)? Which sub-processors may the provider use and how do you find out about changes? How are export and exit regulated? And what applies to generated content with regard to IP/copyright?
So that this does not remain vague, you should mentally separate three packages:
- Data protection contractual foundation (AVV/DPA).This is less about “do we have a document” and more about clean role logic and robust obligations: Earmarking, instruction rights, TOM reference, deletion, audit and control rights, sub-processors and support access. If this is vague, any subsequent discussion will be tough.
- Third country and transfer mechanism (SCC & Co.).As soon as data or even just support/telemetry runs in structures that are relevant outside the EU, you need to know which transfer mechanisms apply and whether additional measures are necessary. This is not “data protection nitpicking”, but a standard topic in audits.
- GenAI-specific legal issues: IP/copyright, indemnity and liability. With traditional SaaS tools, output is usually “your output”. With GenAI, this is more complicated: what assurances does the provider make about training data, how are rights to outputs regulated, and is there indemnity if IP claims arise and under what conditions? This determines whether you are allowed to use the tool in critical contexts later on or whether it remains limited to a “playground” for fear of liability.
A pragmatic requirement for decision-makers: You don’t have to legally assess every detail yourself. Above all, they need to ensure two things: Legal gets the right, structured questions (so that the review doesn’t end in a fog) and Procurement doesn’t only negotiate once the technical facts have already been created. Because as soon as teams get used to a tool, contract drafting quickly turns into damage limitation.
Step 6 - Quality & safety: So that results remain reliable
An AI tool can look clean from a contractual and data protection perspective and still be operationally risky. The reason is simple: If results are unreliable, teams either continue to use the tool incorrectly (“it’ll be fine”) or they circumvent rules (“then I’ll just use a different tool”). Both are bad: for quality, for costs and ultimately for your compliance.
For decision-makers, it boils down to two questions: How do we measure quality in such a way that it is sustainable in everyday life? And: How do we prevent the system from doing things that we don’t want it to do – intentionally or by mistake?
The short answer: Define measurable acceptance criteria before go-live, test with realistic tasks and monitor during operation with a few, clear key figures.
What does that mean in practical terms?
You do not define “80% are good”, but specific error patterns that are relevant for your use case. For example: What types of errors are tolerable (tone of voice, style) and which are not (wrong facts, wrong figures, wrong legal information)? Where is hallucination particularly critical, for example in customer communication, finance, HR or technical instructions? What leakage risks are conceivable (e.g. internal information being leaked via prompts or contexts)? And what content is simply taboo for you (compliance, discrimination, confidential data, IP risks)?
Then don’t test with “demo prompts”, but with real tasks from your everyday life: typical tickets, typical emails, typical evaluations. This will give you a reliable impression: does the tool really help – and under what guidelines?
And finally: In operation, you do not measure 30 metrics, but a few that control. For example: proportion of critical error cases, policy violations (e.g. prohibited data in the prompt), security anomalies, complaints/incidents and response times. In this way, safety does not become a one-off check, but a component that runs with the tool – even if models, features or data sources change.
Step 7 - Operation & governance: Who controls the tool and who is liable in the event of an emergency?
AI tools do not have a business impact when they are “activated somewhere”, but when they run reliably. In practice, reliable means that you can explain data flows, control access, manage contracts and obligations, measure the quality of results – and follow up on changes in operations. It is precisely then that compliance does not become a brake, but a prerequisite for being allowed to scale.
Conclusion
AI tools do not have a business impact when they are “activated somewhere”, but when they run reliably . In practice, reliable means that you can explain data flows, control access, manage contracts and obligations, measure the quality of results and cleanly track changes in operations. It is precisely then that compliance does not become a brake, but a prerequisite for being allowed to scale.
FAQ
Short: You ensure that an AI tool Legally permissible, technically secure and auditable can be operated. This is possible if you clearly classify the use case and risk, monitor data protection and security, draw up contracts/verifications properly and manage operations with clear responsibilities.
No. An AVV/DPA is only one building block. Without clear data flows, access controls, technical and organizational measures (e.g. logging, DLP) and a clearly defined purpose, the risk remains in practice and the audit will be unpleasant.
If a high risk is likely to arise for those affected. This is typically the case with profiling/scoring, sensitive data, large amounts of data or when AI prepares decisions that have real consequences for people (e.g. HR). If you only clarify this after go-live, DSFA often becomes a full stop.
No, but a strong signal. Certificates show that management systems and controls are in place. The decisive factor remains whether the specific product and your operating mode in scope and whether the controls match your risk (e.g. integrations, data types, regions, logging).
Because poor or uncontrolled results quickly lead to real damage This can lead to: false statements in customer communication, incorrect decisions, unwanted content or data leaks via prompts/outputs. That’s why you need acceptance criteria and tests with realistic tasks before go-live – and monitoring with a few, clear key figures during operation.
You might also be interested in
AI in HR What really works and what you should leave alone The short answer AI in the HR worthwhile itself, when You Use Cases along of the Employee Lifecycle prioritize (Recruiting, Service, DevelopmentAnalytics), the Data basis clean limit and governance right from the start help build. Critical becomes it,
