ME-TA is a Danish data processor under GDPR and Danish law. This page describes where your data goes, who sees it, and what is retained where — under which contractual instrument.
TL;DR. A sponsor uploads data through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland) under the AWS GDPR Data Processing Addendum. ME-TA operators on company-owned, BitLocker-encrypted PCs run a WinForms client that executes a three-stage workflow locally on the PC — work/ (human-actor), sce/ (machine-only deterministic SAS / R compute on the PC, no AI), and ai/ (Claude Code on the PC, with files staying local; only the AI prompt and completion travel out to AWS Bedrock in eu-central-1, Frankfurt for inference — curated operational content only; in our standard configuration, patient and sample data are excluded from the AI leg, with per-engagement configurations available under sponsor DPA terms). The entire client-work data chain is intra-EEA — no GDPR Chapter V transfer occurs. The engaged sub-processor is AWS EMEA SARL (Luxembourg) for storage and AI inference; Anthropic is the upstream model author and is not engaged as a separate sub-processor on the Bedrock path. Breach-notification commitment: 24 hours to the controller, well inside the 72-hour GDPR maximum.
Before the architecture detail below, the four areas a sponsor's IT and procurement function typically check first. Each is grounded in a named control, not an abstract claim.
Cognito user pools with MFA; SAML / OIDC federation to the sponsor's identity provider (Entra ID, Okta, or equivalent).
Sponsor users sign in with their corporate credential. No separate ME-TA password to manage; account lifecycle stays in the sponsor's IdP.
Customer-scoped Amazon VPC; private subnets for the data plane; KMS encryption at rest. Regions: eu-west-1 (storage) + eu-central-1 (AI inference).
Sponsor data does not commingle across tenants. No transit outside the EEA — no GDPR Chapter V trigger.
21 effective policies (P01–P21) plus 4 in-flight drafts for AI-usage governance (P07/P16/P21 revisions, P22 new); version-controlled; named policy owners; change-control discipline. Covers 21 CFR Part 11, EU Annex 11, ICH E6(R3), GDPR, AI usage.
Audit-traceable; drafts are publicly visible alongside effective versions so reviewers see the change pipeline, not just the static state.
Art. 28 obligations, intra-EEA processing, 24-hour breach notification, dedicated AI-specific addendum, sub-processor change-notice (30 days).
The four substantive procurement gates pre-handled in ME-TA's standard template at policy.me-ta.dk. Each sponsor's executed DPA reflects modifications negotiated to meet that sponsor's specific requirements, under counsel review.
The diagrams below refer to Category A and Category B. These are ME-TA's two data classes for AI processing, defined in P22-AI Usage §22.4 and used in the same way in every ME-TA DPA. The same vocabulary runs through SVGs 1–4, the sub-processor schedule, and the AI addendum.
SAPs, protocols, investigator brochures, table/listing/figure shells, SAS/R programs, define.xml, dataset specifications, SOPs and QMS templates, regulatory correspondence (FDA, EMA, notified bodies), reviewed context files, blank CRF templates.
No patient-level data; no trial-subject identifiers. The day-to-day work products of statistical programming and regulatory writing.
Patient-level clinical data (including completed CRFs), randomisation codes, unblinding information, unblinded interim or final results, trial-subject PII (name, DOB, address, hospital/national ID), customer-proprietary data without sponsor-DPA AI permission, US PHI under HIPAA.
A leak here would be a clinical-integrity or compliance event. Structurally excluded from the AI leg in our standard configuration.
Elevated-sensitivity content is a sub-class of Category A where a leak would carry material competitive harm to the sponsor — for example, device-specific failure analyses, post-market surveillance root-cause investigations, or trade-secret methodology. Routes through the same AI inference architecture as other Category A content, with an additional named-reviewer pre-submission gate (P22 §22.6).
Standard configuration vs per-engagement. ME-TA's standard offering is the classification above. Sponsors who require a different split — for instance, AI use on a Category-B-class data set under their own DPA and risk-control framework — can have a per-engagement configuration; that is negotiated as a sponsor-specific modification to the standard DPA, not by changing the categories themselves.
Seven steps from sponsor upload to sponsor deliverable. Steps 4–6 are the SCE ↔ AI iteration loop; the loop runs as many times as the work requires, and only step 7 returns un-redacted material to a human. The data flow in SVG 1 below is this same workflow rendered visually.
Datasets, protocol, investigator brochure, SAP, CRF templates, prior submission files — all uploaded by the sponsor through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland). Lands in the WORK stage; nothing has moved to AI yet.
A ME-TA data processor reviews the sponsor's upload and promotes files to the AI stage according to what the per-engagement DPA permits. Typical promoted content: dataset metadata (the schema, not the data itself), redacted confidential documents, specifications, regulatory correspondence — i.e., Category A files per P22 §22.4. The DPA scopes which files may be promoted; ME-TA the data processor performs the review and the promotion. Discretionary human act — no file enters AI without it.
Claude Code on AWS Bedrock (Frankfurt) drafts SAS programs from the promoted Category A specifications. Files stay local to the operator endpoint; only prompts and completions traverse the network, intra-EEA throughout.
The SAS programs run on the Statistical Computing Environment — validated, deterministic, no AI present, no human in the loop during execution. Full datasets are used here. Outputs and logs are produced.
Log files and redacted outputs flow back to the AI stage as context for the next iteration.
AI revises the SAS programs based on the redacted logs and outputs. Steps 4 → 5 → 6 loop until the programs run clean and produce the expected deliverables.
The ME-TA data processor reviews un-redacted outputs in the WORK stage — full data access by a human, no AI present at this step. Approved deliverables are returned to the sponsor through metawebservice.com.
A sponsor's data follows a deterministic path from upload through ME-TA's three-stage architecture and back to the sponsor as deliverables. Every box and arrow below is under contractual coverage of the AWS GDPR DPA or ME-TA's own QMS controls.
End-to-end data flow. The three inter-stage control gates (human-gated promotion, SAS-file submission, automated redaction) are described in the narrative bullets below — this diagram answers "where does data physically go?" only.
meta-cli sync with S3 for sponsor exchange.Each transition between stages inside the WinForms client is controlled — by humans, by structural design, or by an automated filter. None of these controls is shown on the diagram above (which answers only "where does data go?"); they are stated here in prose:
Each row below is an actor in or around the data flow. Each column is a class of data. A cell shows the maximum visibility under normal operations; least-privilege controls in our QMS reduce actual visibility further per engagement role.
* ME-TA admin / DPO visibility into clinical content is gated by customer-admin authorisation per P07 §7.10 and P21 §21.8. ME-TA personnel do not readily have access to customer content unless the customer has granted access.
What is kept, where it is kept, how long, and under which contractual instrument.
Client-work retention only. ME-TA's internal-only use of consumer-tier Anthropic (no client content) is described in a separate note below.
Separate from anything on the diagram above: ME-TA uses consumer-tier Anthropic (e.g. Claude Max) for internal work only — platform development, internal documentation, learning. No client content ever travels this path, per P22 §22.3.4. Conversations on this path live on Anthropic infrastructure in the United States under Anthropic's Consumer Terms (indefinite until operator-deleted, +30 day backend grace, T&S exception up to 2 years for inputs/outputs and 7 years for classification scores). Anthropic on this path is not a sub-processor of ME-TA — it is ME-TA's own tool vendor for internal-only purposes, with no controller-processor relationship arising.
Sections 1–3 above answer the procurement / DPO questions: where data goes, who sees it, how long it's kept. This section is for the IT-security review: nine specific boundaries the architecture is designed to maintain, the layered controls behind each, and what specifically enforces them. Read it if you are mapping our controls to a security framework (ISO 27001 Annex A, SOC 2 CC, NIST SP 800-53) or running a vendor risk assessment.
Rows 1–7 are derived from context/operations/data-flow.md §7 (trust boundaries + enforcement). Rows 8–9 (prompt-injection mitigation; audit log tamper-evidence) are AI-specific and audit-integrity additions per the IT-security review.
CLAUDE_CODE_USE_BEDROCK=1, SKIP_PROMPT_HISTORY=1, WebFetch · survey · feedback disables). These come from the operator-endpoint hardening profile below — every named control is delivered via managed endpoint policy and verifiable on any operator PC.The matrix above names controls in shorthand. The managed-settings baseline below is how ME-TA delivers those controls on operator PCs — through endpoint policy at the Windows registry under HKLM\SOFTWARE\Policies\ClaudeCode\Settings, macOS com.anthropic.claudecode managed preferences, or /etc/claude-code/managed-settings.json on Linux/WSL — at managed scope, which has higher precedence than user or project settings and cannot be overridden locally.
/status and via the managed-settings store. Procurement reviewers who want the current profile (vs. the dated snapshot) should request it at engagement time.
CLAUDE_CODE_USE_BEDROCK=1 forces Bedrock-only routing at the application layer; ANTHROPIC_DEFAULT_SONNET_MODEL pinned to a version-specific ID prevents silent model changes (supports validated state under GxP); absence of CLAUDE_CODE_USE_MANTLE keeps invocations captured by Bedrock model-invocation logging (Mantle is not captured); AWS Service Terms §1.14 carries the contractual non-training claim that the technical posture demonstrates is real.AWS_REGION pinned to an approved EU region delivered via managed policy (not read from .aws/config); model IDs are version-specific in-region IDs, not geo or global cross-region inference profiles, because geo can still move prompts across the EU geography and global can route worldwide. IAM/SCPs enforce the same region constraint at the AWS account level.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (session-quality surveys), CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 (post-session prompt), DISABLE_FEEDBACK_COMMAND=1 (the /feedback command). skipWebFetchPreflight: true closes the domain-safety preflight call to api.anthropic.com. WebFetch in permissions.deny closes the tool itself (preflight-only-disable is not enough on its own). Network-layer FQDN blocks at proxy/firewall provide a redundant outer ring.CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 disables the default plaintext transcript store at ~/.claude/projects/ entirely. Combined with BitLocker AES-256 full-disk encryption, no prompt content persists on disk in recoverable form.disableAllHooks: true, allowedMcpServers: [], and strictKnownMarketplaces: [] remove the agentic tool surfaces that an adversarial prompt could attempt to invoke. The shell-network entries in permissions.deny (curl, wget, Invoke-WebRequest, Invoke-RestMethod) close the obvious exfiltration paths a prompt could ask the AI to run..env, secrets/, .pem, .key, and SSH key paths prevent the AI from reading credentials or sensitive paths even within an approved engagement — defence-in-depth on top of the Cat-A promotion gate.The two placeholders (<approved-eu-region>, <approved-version-specific-bedrock-id>) are deployment-specific and held in ME-TA's deployment register. The profile is reviewed at each Claude Code release and on the P22 §22 annual cycle. Evidence of the profile being in effect on any operator endpoint can be produced on request — Claude Code's /status command shows the active provider, region, model IDs, and disabled features.
ME-TA's contractual sub-processor chain for client work.
| Sub-processor | Role | Location | Instrument |
|---|---|---|---|
| Amazon Web Services EMEA SARL (Luxembourg) — infrastructure | S3 storage, Aurora metadata, Cognito auth (SCE compute runs locally on the operator's PC, so AWS is not a sub-processor for that stage) | AWS eu-west-1 (Ireland) primary; eu-north-1 / eu-central-1 as DR | AWS GDPR DPA (auto-incorporated, Service Terms §1.14.1) |
| Amazon Web Services EMEA SARL (Luxembourg) — AWS Bedrock | AI inference for Category A content (Anthropic Claude models on AWS Bedrock; no provider-side retention; no training) | AWS eu-central-1 (Frankfurt) primary | AWS GDPR DPA (auto-incorporated, Service Terms §1.14.1) |
| Ancillary business sub-processors | Engagement administration only (email, document exchange, scheduling) — no clinical data | Per supplier disclosure | Supplier DPA (under ME-TA P05 / P17) |
Under the AWS Bedrock access pattern, ME-TA's controller's prompts and completions do not flow to Anthropic. AWS hosts the model weights under license from Anthropic and operates the inference service on AWS infrastructure; prompts and completions are not shared with Anthropic. Applying GDPR Art. 4(2) / 4(8) and the EDPB Guidelines 07/2020 factual-nexus test, Anthropic does not factually process ME-TA's controller's data on this path and is therefore not engaged as a processor under Art. 28. The Art. 28 contract is with AWS. Anthropic is the upstream model author — a tool licensor — analogous to Microsoft for Word or the PostgreSQL Global Development Group for AWS RDS for PostgreSQL.
The full rationale, including honest caveats and the procurement walk-through, is available on request as part of the DPA package.
The contractual and policy instruments behind the architecture above.
Auto-incorporated into AWS Service Terms §1.14.1 — covers all AWS-hosted data including Bedrock inference.
Download PDF →The clause that auto-incorporates the AWS GDPR DPA into every AWS customer agreement.
View on aws.amazon.com →ME-TA's AI policy: approved tools, three-stage architecture, data classification, operator hygiene, AI Act compliance.
View on policy.me-ta.dk →ME-TA's GDPR policy, sub-processor register, encryption framework.
View on policy.me-ta.dk →Sponsor-tailored Article 28 DPA. Sent on request — combines the main DPA and the AI-specific addendum, with sponsor entity details substituted.
Request via email →Live sub-processor register at policy.me-ta.dk — kept current under 30-day change-notice per P21 §21.11.
View on policy.me-ta.dk →We provide an Article 28 DPA tailored to each engagement — entity details, Annex C scope, and AI-addendum elections. Our standard turnaround for the first draft is one business day.
Email contact@me-ta.dk