An AI Vendor's Compliance Badge Is Not an Audit Packet

Decision first. Do not approve an AI product for a real workflow merely because its website says “GDPR compliant,” displays a certification logo, or offers a reassuring trust score. Approve a specific use of a specific product configuration only after the buyer can connect each consequential claim to current, scoped evidence, identify the obligations that remain with the buyer, and name the person who accepts each unresolved risk. A small, well-bounded pilot with synthetic data may be appropriate while material documents are missing. A production rollout involving personal or confidential data is a different decision.

This article gives a reusable evidence-packet protocol for a procurement, privacy, security, or product team. It is not a declaration that any named supplier is compliant, nor a substitute for counsel or a data protection officer. The practical question is: if an auditor, regulator, customer, or incident responder challenged the decision tomorrow, could a colleague reconstruct what was checked, for which workflow, on which date?

This overview of GDPR and AI tools covers legal bases, transfers, impact assessments, and vendor diligence. Its broad checklist is useful orientation, but a list of questions is not yet a reproducible purchasing decision. The missing operational piece is the mapping from a supplier's statement to a document or test, the exact product boundary, a dated reviewer decision, and a trigger to revisit that decision when the service changes. We build that piece below. Where the overview uses broad claims about products or legal consequences, verify them against primary sources and the actual contract rather than copying them into a procurement record.

What existing guidance covers—and what the buyer still has to decide

The Polish data protection authority, UODO, published separate initial-question sets for SMEs using ready-made AI, public bodies, other organisations, and cases warranting an extended GDPR-plus-AI-Act review. It says these questions are a starting point, not a risk analysis, impact assessment, or binding finding of compliance. That is a useful boundary: a completed questionnaire does not close the file. UODO's explanation and downloads support that distinction. The guidance is from Poland; an organisation elsewhere must still apply the rules and supervisory guidance relevant to its own processing.

The European Data Protection Board hosts a support-pool AI-auditing checklist. The page explicitly says the document was prepared by external contractors and does not necessarily represent the Board's official position. Its value here is as an audit-workpaper model, not as a binding regulatory verdict. It directs an assessor to record whether underlying documentation exists or is unavailable, rather than treating a high-level model description as proof. See the EDPB project page and provenance note. This provenance matters: “hosted by a regulator” and “adopted regulator opinion” are not synonyms.

The EDPB's adopted Opinion 22/2024 gives a more direct controller-and-processor example. It says a controller should know the identities of its processors and subprocessors and verify their sufficient guarantees, with the extent of verification varying by processing risk. It also says controllers need not systematically demand every subprocessing contract; they should decide what is necessary to demonstrate compliance. This is a useful correction to the simplistic demand for a mountain of documents from every vendor. EDPB Opinion 22/2024 is the underlying adopted source.

The OECD AI principles frame accountability as traceability and ongoing, context-sensitive risk management across an AI system lifecycle. This is a recommendation, not a substitute for a GDPR legal basis or a technical test. Deloitte's chief legal officer discussion of third-party generative AI similarly argues for documenting vendor credentials, obligations, capabilities, and ownership of due diligence. Deloitte is a consulting perspective, not a regulator. These sources converge on an important operating principle without proving that every vendor audit should use the same paperwork.

A Law Society of Ireland vendor assessment tool, developed with an advisory firm, covers data location, training use, contract adequacy, human oversight, exit, and ongoing governance. Its traffic-light scoring is a decision aid for legal practice; a high aggregate score cannot logically cure a missing lawful processing arrangement for a particular use. That is an inference from the difference between a compensating score and a hard requirement, not a claim made by the source. In our protocol, hard blockers are decided before any weighted comparison.

The search results for vendor assurance also contain sales-led “audit-ready” claims and webinar descriptions. A webinar description can reveal the questions teams are asking, but it is not evidence that a platform can produce the documents in your contract. I found no accessible authoritative video transcript that changed the controls below. The gap is more concrete: buyers need a compact record that distinguishes claim, evidence, scope, decision, and expiry. That is the information gain in this guide.

Start with a use-case boundary, not a supplier brand

Write one sentence describing what the tool will actually do. “We are buying an AI assistant” is not enough. “A customer-support agent will summarise inbound email containing account identifiers and suggest replies to human staff, without sending messages” is a reviewable scope. The same vendor may present a different risk if the assistant receives health records, decides eligibility, reads an entire shared drive, or can send and delete messages autonomously.

Record the input classes, output consumers, accessible systems, user groups, region, retention needs, and actions the tool may take. Identify who determines the purposes and means of processing; do not assume the vendor's standard label settles the role for every feature. The EDPB's controller/processor opinion makes the buyer's responsibility to understand and verify the processing chain explicit (EDPB). If an optional “improve the model” setting uses submitted data for a vendor purpose, that may demand a separate analysis rather than being absorbed into the buyer's original use case.

For the running example, suppose a mid-sized EU services firm wants an AI tool to summarise support tickets. The proposed pilot uses invented tickets. Production would include names, email addresses, contract details, and occasional free-text complaints. The assistant is read-only and a human approves all replies. The buyer's first task is to prevent a pilot approval from silently becoming production authorisation. Mark the data class, integration permissions, and environment in the decision record. A screenshot of a “no training” switch in a test tenant does not prove the switch is active in production.

Draw the service path before requesting compliance documents. A ticket may pass through the buyer's help desk, an integration broker, the AI vendor, a separate model provider, logging services, support tooling, and backups. “Hosted in the EU” might refer only to primary storage; it does not answer where model inference, remote support, telemetry, or disaster recovery operates. Ask the supplier to identify these paths, then compare the answer with the contract, subprocessor list, and configuration you will actually deploy. A data-flow diagram with unknown boxes is more honest than a polished one with omitted flows.

The use-case boundary should also specify what is out of scope. In the example, the tool must not make account-closure decisions, send outbound mail, retrieve tickets outside the assigned queue, or ingest attachments until those functions receive separate review. This prevents a favorable assessment of a narrow summariser from being reused as an all-purpose procurement pass. It makes future change review practical: a new feature can be evaluated against an explicit baseline.

The original asset: a claim-to-evidence decision packet

Use a packet with five linked records: (1) use-case boundary, (2) supplier claim register, (3) evidence manifest, (4) exceptions and decisions, and (5) re-review triggers. Each supplier claim gets an identifier; each piece of evidence gets a separate identifier and date. The reviewer records which claim an artifact supports and whether the artifact covers the proposed product, tenant, region, feature, and period. “Evidence available” is not the same as “evidence supports this claim.”

Here is a compact register. The rows are illustrative requests, not findings about a real supplier. The stop conditions are recommended operating gates; local counsel should confirm legal necessities for the actual processing.

Claim to test	Evidence to request	Scope check	Recommended decision if missing
“We process only on your instructions”	Signed processing terms and feature-level data-use description	Which inputs, outputs, telemetry, and support records?	No personal-data production use until roles and instructions are resolved
“Your prompts do not train models”	Binding terms, tenant setting, and a dated configuration export	Does it include feedback, attachments, logs, and each model route?	Synthetic-data pilot only, with training path disabled and verified
“Data stays in the EU”	Processing-location map and subprocessor/remote-access list	Inference, storage, support, backups, and onward transfers	Do not represent an EU-only arrangement without resolving every path
“We are independently audited”	Complete report or certificate, scope statement, period, exceptions	Legal entity, service, cloud environment, and AI feature	Treat badge as unverified for this workflow
“We can delete everything”	Contractual deletion terms and a tenant-level test or documented procedure	Files, embeddings, logs, backups, support tickets, derived records	Set retention exception and owner; do not promise immediate total erasure
“The assistant cannot act without approval”	Permission model and test showing blocked send/write actions	Production integration, service account, delegated roles	No production write capability until tested
“We notify you of incidents and changes”	Contract clause, notification path, sample notice, change log	Model, region, subprocessors, training terms, security events	Escalate contract gap before launch

Why separate a claim register from an evidence manifest? One document can support several claims, but only within its scope. A general security policy may show that a control is designed; a dated system export may show it was configured; a test or independent report may show it operated. These are different levels of assurance. A copied vendor answer without the underlying artifact should be marked self-attested. The Law Society tool deliberately reserves an evidence/notes field next to each criterion (assessment PDF); the packet makes that relationship explicit and reviewable across business functions.

For every evidence item, record artifact_id, owner, issue date, period covered, product/service, environment, relevant page or control, sharing restriction, reviewer, and review date. The packet should keep a secure reference to restricted documents, not paste a confidential audit report into an unrestricted wiki. If a supplier will share a report only under NDA, record the access path and whether the authorised reviewer actually read it. “Report requested” is not “report reviewed.” If the report excludes the exact AI feature, write “out of scope” rather than stretching its meaning.

Do not build a numerical “trust score” before establishing non-negotiable conditions. A score can help compare two suppliers after they pass the hard gates. It cannot make a missing processor contract disappear. The UODO guidance explicitly warns that initial questions are not a compliance determination; the packet therefore contains an outcome and rationale, not a green badge alone. Outcomes are approved for stated scope, conditional pilot with stated restrictions, deferred pending evidence, or rejected for stated scope. No generic “approved vendor” state is needed.

Verify each claim at the right assurance level

Begin with document identity. A certification may apply to a parent company but not the acquired product you use. A contract may name one service tier while your team uses another. A DPA signed years ago may not reflect a new model provider. A security report can have a valid date but a service boundary that excludes the feature you care about. Ask, “Does the artifact cover this service and this workflow during the decision period?” If the answer is no, record a gap, even if the marketing page and certificate are both authentic.

The distinction is especially important for an AI management-system claim. ISO's description of ISO/IEC 42001:2023 identifies it as a standard for establishing and continually improving an organisational AI management system. ISO explains that it concerns governance across an organisation rather than the details of every specific AI application. Therefore, a certificate can be relevant evidence about management processes, but it is not by itself a test result for your particular data path, model route, or integration. That last sentence is an inference from the standard's stated scope, not an accusation against certified suppliers.

Next separate a design claim from an operating claim. A policy that says staff access is approved is design evidence. A sample of access approvals, system-enforced role settings, and revocation records is operating evidence. Neither should be fabricated to make a procurement spreadsheet look complete. The EDPB's opinion says verification is required but should be proportionate to the risk of the processing (EDPB). That is why a dated check has a review interval and a change trigger, rather than a one-time checkbox.

Then verify data-use promises by category. Prompts, files, outputs, embeddings, feedback, telemetry, abuse-monitoring logs, support tickets, and backups may have different retention and access rules. “No training” is not the same as “zero retention,” and “zero retention” is not the same as “no transient processing.” Ask for precise definitions in the supplier's terms and configuration documentation. Test deletion where the product exposes a testable deletion action, and document categories that remain under backup or legal retention. Do not claim a deletion guarantee from an interface button alone.

Transfers deserve similar precision. Location of a dashboard is not location of every processing activity. The buyer should map hosting, inference, subprocessors, support access, and onward transfers. If a transfer mechanism is required, get the instrument and any supporting assessment from counsel or the privacy owner; an address on a vendor's website is not a transfer mechanism. The Law Society assessment separately asks for data-processing location, transfer mechanism, and subprocessor transparency, which makes the distinction visible. The exact applicable obligations depend on jurisdiction and facts.

Finally verify capabilities. A “human in the loop” slide is not enough when the integration token can send mail, alter records, or download files. Make a permission inventory and attempt a safe negative test in an isolated tenant: can a prompt or workflow cause an unapproved write? Record the test date, role, environment, command or UI path, expected result, actual result, and limitations. For a read-only summariser, the target result is that send/write operations fail due to technical permission boundaries, not because the assistant politely declines in a demonstration.

A worked decision: ticket summarisation without a false green light

Return to the EU support-ticket example. The supplier provides a privacy page, a draft DPA, a subprocessor list, a general security certificate, and a sales assurance that customer content is not used for training. The buyer also receives a screenshot of a “no model improvement” setting. The system owner can see that the proposed integration has read access to the full help-desk account rather than one queue. The DPA has not been signed. The certificate covers the vendor's core application but does not specify its new AI feature. These are hypothetical facts, not measured claims about a named service.

The first packet row records the approved purpose: internal drafts of ticket summaries, no automatic customer response. It lists the planned data fields, excludes attachments, and names the support manager as business owner. Privacy counsel decides whether the proposed data processing terms and transfer documentation meet the actual legal needs. Security owns the integration scope and permission test. The vendor must clarify whether support personnel or downstream model providers can access ticket contents. Every open question has an owner and a due date; “awaiting vendor” is not an owner.

For this example, the defensible interim outcome is conditional synthetic-data pilot, not production approval. The pilot uses fabricated tickets, an isolated account, no production help-desk token, and no personal data. This outcome permits the team to test summarisation quality and operational usefulness without pretending that the DPA or AI-feature assurance gap is solved. When the supplier returns a signed DPA, a product-specific scope statement, a complete processing path, and the integration is restricted to the intended queue, the team performs a new review. If an essential item remains unavailable, the decision remains deferred. A procurement deadline does not convert an unknown into a verified fact.

Notice the difference between “safe enough to pilot” and “legally cleared for production.” A privacy review may conclude that a DPIA is not necessary for a low-risk narrow use, or that one is necessary because of the actual processing; the article cannot pre-decide that. The UODO initial and extended-question sets explicitly distinguish a first screen from deeper assessment. A team should preserve that branching logic instead of turning every deployment into the same massive form or, conversely, treating every form as sufficient.

The decision packet should include a short counterfactual: “What evidence would change our answer?” For the ticket example: signed and scope-matched terms; a documented data flow with all subprocessors and locations; confirmation of training restrictions for this tier; production configuration evidence; a successful negative permission test; and a named reviewer sign-off. This makes a deferred decision actionable. It also prevents a supplier from repeatedly sending new marketing material that does not answer the actual gap.

The evidence flow, including re-review

flowchart TD
  A[Define one AI use case and data boundary] --> B[Map product, integrations and subprocessors]
  B --> C[Register each consequential supplier claim]
  C --> D[Attach dated, scope-matched evidence]
  D --> E{Hard blocker unresolved?}
  E -- Yes --> F[Defer production or restrict to synthetic pilot]
  E -- No --> G[Run configuration and negative tests]
  G --> H{Tests and reviewer sign-off pass?}
  H -- No --> F
  H -- Yes --> I[Approve stated scope with conditions]
  I --> J[Monitor model, region, access and term changes]
  J --> K{Material change?}
  K -- Yes --> C
  K -- No --> L[Review at scheduled interval]

This is an operating model, not an assertion that a diagram satisfies a legal requirement. Its advantage is that approval is scoped and revocable. A model switch, new subprocessor, permission expansion, or change in data categories leads back to claim verification, not merely to a note in the vendor directory. The OECD accountability principle supports ongoing traceability and risk management; our loop is one implementation choice for procurement teams.

For a small organisation, the diagram can be implemented in an existing ticket system. A request ticket holds the use-case boundary. Evidence IDs point to controlled document storage. An exception ticket names the missing item, temporary restriction, owner, and deadline. A decision record links the request and exceptions. A change feed or contract calendar triggers re-review. Do not buy an additional governance platform merely to draw this flow; test whether the controls can be operated by the people who already own them.

A small executable preflight for the packet

The following Python checks only packet completeness and scoping. It does not decide GDPR compliance, validate document authenticity, interpret a contract, or test a deployed system. It is deliberately narrow: a machine can detect missing owners and stale artifacts, while a qualified reviewer judges whether the evidence actually supports a claim. The sample contains three invented records so that it cannot be mistaken for a supplier audit.

from datetime import date

TODAY = date.fromisoformat("2026-10-22")
USE_CASE = "synthetic-ticket-summary-pilot"
claims = [
    {"id": "C1", "claim": "no training on pilot inputs", "use_case": USE_CASE,
     "evidence": "E1", "owner": "privacy", "reviewed": "2026-10-20",
     "expires": "2026-11-20", "status": "reviewed"},
    {"id": "C2", "claim": "write permission blocked", "use_case": USE_CASE,
     "evidence": "E2", "owner": "security", "reviewed": "2026-10-21",
     "expires": "2026-11-21", "status": "reviewed"},
    {"id": "C3", "claim": "production DPA signed", "use_case": "production-tickets",
     "evidence": "", "owner": "legal", "reviewed": "", "expires": "",
     "status": "open"},
]

def packet_errors(rows, use_case, today):
    errors = []
    for row in rows:
        if row["use_case"] != use_case:
            continue  # A separate production decision is required.
        for field in ("id", "claim", "evidence", "owner", "reviewed", "expires"):
            if not row.get(field):
                errors.append(f'{row.get("id", "?")}: missing {field}')
        if row.get("status") != "reviewed":
            errors.append(f'{row.get("id", "?")}: not reviewed')
        if row.get("expires") and date.fromisoformat(row["expires"]) < today:
            errors.append(f'{row["id"]}: evidence review expired')
    return errors

errors = packet_errors(claims, USE_CASE, TODAY)
print("PACKET PREFLIGHT PASS" if not errors else "\n".join(errors))

Running this sample prints PACKET PREFLIGHT PASS for the invented synthetic pilot. It intentionally ignores C3 because C3 belongs to the production use case, and that is the point: a pilot pass must not automatically approve production. If you switch USE_CASE to production-tickets, the checker reports missing evidence, review, expiry, and an open status for C3. A real workflow should also check that evidence IDs exist in the manifest, dates parse, document scope matches, approvals are authorised, and exceptions are linked. Add these checks only after the packet schema is stable; a large validator cannot compensate for ambiguous inputs.

Method and limits for this original asset: designed on 22 October 2026 from the publicly available authority and professional materials cited in this article. Sample size is one invented use case and three invented claim records. No supplier documents, real customer data, or live vendor systems were tested. The output demonstrates deterministic completeness logic, not a measured reduction in incidents or proof of regulatory compliance. The exclusions are deliberate so nobody can cite the sample as an evaluation of a product.

What the packet should prove, and what it cannot

An audit packet should make the decision reconstructable: here is the use, the data path, the contract version, the artifact reviewed, the configuration seen, the test run, the exception accepted, and the people who approved. It should also reveal uncertainty. The presence of a DPA does not show that every processing operation is lawful. A valid certificate does not show that a prompt will not be exposed through a misconfigured integration. A successful test today does not guarantee the behavior of a future release. Conversely, the absence of a certification does not prove a supplier is unsafe; alternative evidence and a risk-based decision may be possible.

There is a useful tension between broad and narrow guidance. A broad vendor score makes comparison efficient, as the Law Society tool illustrates. The narrower EDPB opinion asks whether sufficient guarantees can be verified for the real processing chain. Both are useful, but they answer different questions. A comparison score can rank eligible options; a scope-matched hard gate decides whether a specific planned use should proceed at all. Treating them as interchangeable creates a false green light.

There is also a tension between risk-proportionate review and paperwork accumulation. Low-risk synthetic exploration should not need the same depth as a tool making consequential decisions about people. The UODO's differentiated initial sets (source) acknowledge varying contexts. But “low risk” must be supported by facts about data and actions. A tool that was read-only last month may now have send permissions; a tool that processed invented records may now receive real customer messages. The packet stays small only if the scope is honestly narrow.

Most importantly, a procurement team cannot outsource its decision to a badge, questionnaire score, or AI-generated audit summary. An AI system can help extract clauses and organise artifacts, but a human reviewer must verify citations, scope, exceptions, and contractual meaning. Deloitte's CLO discussion explicitly treats responsibility for third-party due diligence as an internal ownership decision. Use AI to prepare a review, not to impersonate the accountable reviewer.

Failure modes to plan for before signature

Scope laundering. A certificate for the company's general cloud service is cited as proof about a newly released AI assistant. Ask the supplier for the service description, covered entity, period, exceptions, and whether the AI feature is included. If not, register the gap. Do not relabel an out-of-scope artifact as “partial proof” without specifying what it actually covers.

Temporal laundering. A report was valid when collected but has expired or predates a model, hosting, or subprocessor change. The fix is to store dates and change triggers, not to collect more undated PDFs. Re-review on material change even if the annual calendar reminder is months away. The OECD accountability text treats risk management as ongoing, which supports this cadence as a governance choice.

Pilot-to-production drift. A team receives approval to test with synthetic data, then connects a live CRM or help desk “for realism.” The packet must state environment, data class, permissions, and prohibited actions in the approval itself. A change to any of those is a new decision. A production token should not be issued on the basis of a pilot ticket.

Permission mismatch. Contract says “human oversight,” while the service account can act broadly. Check actual scopes and run a negative test. A human review screen is not a technical control if a separate API path can send or modify data. Keep a failed test as evidence; do not edit the finding away to meet a launch date.

Data-path omission. The buyer checks primary hosting but not model inference, support access, backups, logs, or subprocessors. The remedy is a field-level data-flow map and a list of unknowns. Where cross-border processing matters, the privacy owner evaluates the relevant instrument and facts. Avoid universal statements such as “EU server equals GDPR compliant.”

Questionnaire substitution. A supplier answers “yes” to security questions but provides no dated artifacts. A self-attestation is still information, and sometimes it is all that is available. Record its status and restrict the decision accordingly; do not silently promote it to independently tested evidence. The EDPB-hosted audit work is useful precisely because it keeps available, unavailable, and not-applicable documentation distinct.

Ownerless exception. Legal assumes security is handling a missing deletion term; security assumes procurement is negotiating it. Every exception needs a named owner, treatment, deadline, and explicit approver. If nobody can accept the residual risk, the decision is deferred. This is a management design rule, not a claim that every framework prescribes the same fields.

Marketing-statistic contamination. A source page may cite large penalty ceilings, market totals, or product rankings without the detail needed for your decision. Do not use a dramatic number as the business case for a specific control. The basis is your data, workflow, and obligations. For any original figure in a real packet, record the source, period, denominator, exclusions, and calculation method. This article makes no claim that the packet improves rankings, reduces incidents by a percentage, or produces a regulator-approved “trust score.”

Implementation rhythm for a small team

First, give each proposed AI use a stable ID. A single supplier may have several uses with different data and permissions. Keep a one-page boundary and link to the existing procurement request. If the business owner cannot state the purpose, input classes, outputs, and prohibited actions, pause the review there. No vendor answer can cure an undefined internal request.

Second, request the smallest evidence set that can change the decision. For a synthetic pilot, that might be product terms, account settings, and a negative permission test. For personal-data production, it will usually be broader: role and purpose analysis, signed processing terms where appropriate, subprocessor and transfer information, retention/deletion terms, security scope, configuration evidence, and a documented impact-assessment decision. The EDPB processor opinion supports risk-proportionate verification; apply it with the relevant legal advice.

Third, hold a short review with the business owner, privacy, security, and legal/procurement as needed. Walk through the claim register, not a slide deck. Ask each reviewer what evidence would change an unresolved answer. Log dissent or a conditional approval in the record. A decision that everyone vaguely remembers but nobody can reconstruct is not an audit packet.

Fourth, after approval, monitor the things that can invalidate it: new model provider, expanded integrations, changed training setting, new subprocessors, retention change, significant incident, or a new data class. The packet should state who receives change notices and who opens the re-review. If nobody owns this in-life step, the due-diligence project ends precisely when the real operational risk begins.

Finally, plan exit while the relationship is healthy. Record how to export customer data, revoke tokens, delete tenant data, handle backups, preserve necessary audit evidence, and verify transition. The Law Society tool includes exit and portability as a separate assessment domain. That is a reminder that reversibility is part of choosing a supplier, not a last-minute procurement afterthought.

Validation checklist before a real production decision

• Can a reader identify the exact workflow, data classes, environment, product tier, model route, and integrations covered by the decision?
• Is the supplier's processing path mapped, including model provider, subprocessors, support access, telemetry, backups, and relevant locations?
• Are controller/processor and other role questions decided for the actual processing rather than copied from marketing wording?
• Does each consequential supplier claim have a dated artifact or test with a reviewer, service scope, and expiry or change trigger?
• Have privacy and counsel decided whether processing terms, transfers, and an impact assessment are needed for this use?
• Do the deployed training, retention, access, and logging settings match the documented terms?
• Has a negative permission test shown that forbidden actions fail through the production-style integration?
• Are missing items classified as blockers, conditional restrictions, or accepted residual risks with named owners?
• Does the approval state its limits so a synthetic pilot cannot be misread as personal-data production clearance?
• Is there a re-review owner for model, region, subprocessor, permission, contract, and data-purpose changes?
• Can an authorised colleague retrieve the evidence and reconstruct the decision without relying on a vendor badge or a departing employee's memory?

If the answer to a hard-gate question is unknown, record unknown and constrain the deployment. That is not bureaucratic failure; it is the information the decision-maker actually needs. A useful packet does not proclaim that a vendor is “compliant.” It shows what the organisation knew, what it tested, what it accepted, and what would cause it to change course.