Compliance · GDPR Article 22

GDPR Article 22 and multimodal AI — automated decision-making integrity under prompt injection

GDPR Article 22 restricts automated individual decision-making that produces legal or similarly significant effects, and requires that such decisions be based on accurate data, subject to human oversight on request, and explainable to the individual. When the automated decision is made by a vision-language model that processes image inputs provided by the data subject — a photo for an insurance application, an identity document for KYC, a CV with a profile photo, a medical scan for a health plan — those image inputs are an untrusted attack surface. A FigStep-class adversarial payload embedded in the image instructs the model to return a different output than the document's actual content warrants. The model's decision is then corrupted, the explanation generated for the right-of-explanation request will be factually wrong, and the audit trail — based on text-layer logs — will show no anomaly. Every text-only PI scanner on the market misses this. Glyphward is the missing layer between the image input and the automated decision.

TL;DR

For automated decision systems under GDPR Article 22 that process individual-submitted images: call Glyphward's /v1/scan before the vision LLM decision call. A PI-positive result (score ≥ 60 for high-stakes decisions) stops the automated pipeline and routes to human review. The scan_id becomes part of the decision record, directly supporting GDPR Article 22(3) right-of-explanation documentation and EU AI Act Article 11 technical documentation requirements. Free tier — 10 scans/day, no card.

Why multimodal PI is a GDPR Article 22 compliance risk

The accuracy requirement (Article 5(1)(d)). GDPR requires that personal data used in processing be accurate and, where necessary, kept up to date. Article 5(1)(d) applies to the inputs that inform automated decisions. A vision-LLM automated decision that was made on the basis of a PI-corrupted image was not made on accurate data — the model processed an adversarial instruction, not the actual content of the submitted document. The decision fails the accuracy principle at the data level. From a DPA audit perspective, "we used the image the subject submitted" is not a sufficient defence if the system had no mechanism to detect that the image contained adversarial content.

The right to explanation (Article 22(3) and Recital 71). Data subjects have the right to obtain an explanation of an automated decision and to contest it. If the decision was made by a model that processed an adversarial PI payload in the submitted image, the explanation the controller generates will describe a decision based on the document's apparent content — but the actual driver of the model's output was the injected instruction. The explanation is therefore misleading, even if generated in good faith. A data subject who successfully contests the decision by providing a clean version of the same document will receive a different outcome — evidence that the original decision was not based on the document's actual content.

Intentional manipulation vs system failure. From a liability standpoint, a data subject who deliberately embeds an adversarial PI payload in a submitted document to influence an automated decision in their favour is engaging in fraud. However, the GDPR controller still bears the burden of demonstrating that their system had appropriate technical and organisational measures in place to detect and prevent such manipulation. A controller who did not scan image inputs for adversarial content — when such scanning was technically feasible and commercially available — cannot claim to have implemented "appropriate measures" under GDPR Article 25 (data protection by design and by default).

Special category data in vision-LLM decisions. Automated decisions that process health data, biometric data, or data revealing racial or ethnic origin (all special categories under GDPR Article 9) face stricter requirements. Medical underwriting AI that processes health imaging, identity verification AI that analyses biometric photos, and hiring AI that processes CV photos with demographic information all intersect Article 22 and Article 9. A PI attack on any of these systems that alters a decision about a special-category-data subject creates a compound GDPR exposure.

Use cases: GDPR Article 22 decisions with image inputs

Insurance underwriting from submitted health documents. A life or health insurer's AI underwriting system that processes applicant-submitted medical documents or health photos is an Article 22 automated decision system (access to insurance = significant legal effect). See prompt-injection scanner for insurance AI for the full attack surface and integration guide.

Credit and loan decisions from identity document scans. Lending platforms that use vision AI to extract and verify data from applicant-submitted identity documents (for KYC, creditworthiness assessment, or income verification) make Article 22 decisions if the AI output directly determines loan approval without human review. A PI payload in a submitted document can alter the extracted data — for example, inflating a reported income figure or inserting a false verification status. See prompt-injection scanner for financial services AI for the KYC/lending variant.

CV screening and hiring AI from profile photo or portfolio uploads. Hiring AI tools that accept portfolio images, ID photos for verification, or work samples as image uploads and use vision LLMs to assess candidates are within Article 22 scope if the AI output significantly affects hiring outcomes. An adversarial overlay in a portfolio image can inject instructions that alter the AI's assessment. GDPR Article 22(4) explicitly prohibits automated decisions based solely on special category data (including biometric and ethnic origin data potentially derivable from a photo) unless the data subject has given explicit consent — a scan that flags anomalous PI content in submitted photos adds a layer of process integrity to this already-constrained use case.

Housing and rental applications with property photos. AI systems used to assess tenant applications by processing submitted documents (pay slips scanned as images, bank statements photographed, identity documents) can have significant effects on housing access. PI payloads in submitted photos can alter income assessment or identity verification outcomes.

Python integration with decision-record audit logging

For a GDPR Article 22 compliant automated decision pipeline, the scan result must be persisted as part of the decision record so it is available for right-of-explanation requests and DPA audits:

import base64, httpx, uuid
from datetime import datetime, timezone
from dataclasses import dataclass, asdict

GLYPHWARD_API_KEY = os.environ["GLYPHWARD_API_KEY"]
GDPR_DECISION_THRESHOLD = 60  # conservative for Article 22 decisions

@dataclass
class DecisionAuditRecord:
    decision_id: str
    subject_id: str          # pseudonymised data subject ID (not name)
    decision_type: str        # e.g. "insurance_underwriting"
    image_scan_id: str
    image_scan_score: int
    image_scan_blocked: bool
    model_decision: str | None
    decision_at: str

def make_automated_decision(
    image_bytes: bytes,
    subject_id: str,
    decision_type: str,
    llm_call: callable,
) -> DecisionAuditRecord:
    """GDPR Article 22 automated decision with PI scan and audit record."""
    decision_id = str(uuid.uuid4())
    image_b64 = base64.b64encode(image_bytes).decode()

    # Step 1: PI scan — required before any automated decision on this image
    resp = httpx.post(
        "https://glyphward.com/v1/scan",
        headers={"Authorization": f"Bearer {GLYPHWARD_API_KEY}"},
        json={
            "image": image_b64,
            "source": decision_type,
            "metadata": {
                "decision_id": decision_id,
                "subject_id": subject_id,  # pseudonymised
            },
        },
        timeout=5.0,
    )
    resp.raise_for_status()
    scan = resp.json()

    blocked = scan["score"] >= GDPR_DECISION_THRESHOLD
    model_decision = None

    if not blocked:
        # Step 2: LLM decision — only if image is clean
        model_decision = llm_call(image_b64)

    # Step 3: Persist audit record — required for Article 22(3)
    record = DecisionAuditRecord(
        decision_id=decision_id,
        subject_id=subject_id,
        decision_type=decision_type,
        image_scan_id=scan["scan_id"],
        image_scan_score=scan["score"],
        image_scan_blocked=blocked,
        model_decision=model_decision,
        decision_at=datetime.now(timezone.utc).isoformat(),
    )
    persist_to_audit_log(asdict(record))  # write to immutable audit store

    if blocked:
        raise AdversarialImageDetectedError(
            f"Decision halted: PI detected in submitted image. "
            f"decision_id={decision_id} scan_id={scan['scan_id']}"
        )

    return record


class AdversarialImageDetectedError(Exception):
    pass

When a data subject exercises their Article 22(3) right to explanation, retrieve the DecisionAuditRecord for their decision_id. The image_scan_id and image_scan_score fields document that the image was inspected for adversarial content before the decision was made — evidence that appropriate technical measures were in place under Article 25.

Get early access

Regulatory mapping

RequirementArticleHow Glyphward scan addresses it
Accuracy of data used in decisionsGDPR Art. 5(1)(d)Scanning blocks adversarially corrupted image inputs before they influence the decision output
Right to explanation for automated decisionsGDPR Art. 22(3) + Recital 71scan_id in the decision record documents that input integrity was verified; clean scan is a prerequisite for a valid explanation
Data protection by design and by defaultGDPR Art. 25Scanning image inputs for adversarial content is an appropriate technical measure proportionate to the risk of manipulation in high-stakes automated decision contexts
High-risk AI accuracy requirementsEU AI Act Art. 15PI detection at the input boundary directly supports accuracy and robustness requirements; see EU AI Act Article 15 and multimodal prompt injection
High-risk AI technical documentationEU AI Act Art. 11Scan logs and scan_ids are auditable evidence of the risk-mitigation measure for EU AI Act technical documentation packages
SOC 2 input boundary controlCC6.6Documented scan of every image input from outside the system boundary; see SOC 2 AI security controls

Related questions

Does GDPR Article 22 apply to B2B automated decisions or only B2C?

Article 22 applies to decisions about natural persons — it does not apply to decisions about legal persons (companies). B2B automated decisions involving data about the counterparty company as a legal entity fall outside Article 22's scope. However, B2B decisions that involve data about individuals at the counterparty — creditworthiness assessments of sole traders, employment verification for contractors, background checks on officers — do fall within Article 22 if those individuals have not consented or if the decision produces significant effects on them. In practice, most B2B identity verification and KYC flows involve individual natural persons and are within scope.

We have human review in our pipeline — do we still need to scan image inputs?

GDPR Article 22(2) permits automated decisions when they are necessary for a contract, authorised by law, or based on explicit consent — and in those cases the controller must implement suitable measures to safeguard the data subject's rights, including "at least the right to obtain human intervention." Human review is one of those measures — but it is not a substitute for input integrity scanning. A human reviewer looking at a submitted image will not see a typographic PI payload designed to be imperceptible at human inspection speeds and resolutions. The scan is the technical control that verifies input integrity before human review sees the case — it is complementary to, not a replacement for, human oversight.

What threshold should we use for GDPR Article 22 automated decisions?

For high-stakes automated decisions (insurance access, credit decisions, employment), use a threshold of 60 — more sensitive than the default 70. Scores 60–70 should trigger human-in-the-loop review (the automated decision is paused; a human reviews the original image and the scan result before the decision proceeds). Scores above 70 should trigger a security alert and immediate decision halt. The threshold of 60 reflects the higher cost of a false negative (a missed PI attack corrupting a decision) relative to the cost of a false positive (a legitimate image sent to human review). Adjust based on your false-positive rate over the first 30 days of operation.

Can we use the scan_id in our GDPR transparency notice?

Yes, you can reference the scan mechanism (without exposing the API key or technical details) in your Article 13/14 transparency notice under the "automated decision-making" section. A statement such as: "Submitted documents are scanned by an automated adversarial-content detection service before being processed by our AI decision system" satisfies the Article 13(2)(f) requirement to provide information about "the existence of automated decision-making, including profiling" and gives data subjects meaningful information about the nature of the processing.

Further reading