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 processes the engagement locally on the PC — work/ (human-actor) and sce/ (machine-only deterministic SAS / R compute, no AI). Deliverables return to the sponsor through metawebservice.com. The entire client-work data chain is intra-EEA — no GDPR Chapter V transfer occurs. The engaged sub-processor is AWS EMEA SARL (Luxembourg). Breach-notification commitment: 24 hours to the controller, well inside the 72-hour GDPR maximum.
AI is not part of the base service. AI-assisted production exists only as a per-engagement election, governed by a dedicated AI addendum to the DPA — either ME-TA-operated on AWS Bedrock in eu-central-1 (Frankfurt) (curated operational content only; patient and sample data excluded; files stay local, only prompt and completion text travels; Anthropic is the upstream model author, not engaged as a separate sub-processor on the Bedrock path), or sponsor-operated in the sponsor's own approved AI tenant. See "Deterministic by default — AI only by election" below; the AI detail on this page is collapsed until you expand it.
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) available per engagement.
With federation elected, sponsor users sign in with their corporate credential — no separate ME-TA password to manage, and 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 base engagement runs entirely without AI: human statisticians (WORK) and validated, deterministic SAS / R compute (SCE), governed by the standard Art. 28 DPA. AI-assisted production is an optional election — governed by a dedicated AI addendum and recorded in the DPA's annex elections. The statistical service and its deliverables are the same either way.
The default posture. ME-TA statisticians and programmers deliver through the human and deterministic-compute stages alone; no AI addendum is attached to the DPA.
None of the AI sections on this page apply — the standard DPA alone governs the engagement.
AI drafting on AWS Bedrock (eu-central-1, Frankfurt), Category A content only, under the AWS GDPR DPA and ME-TA's operator-endpoint hardening. This is the AI architecture described in the collapsed sections of this page.
Fastest path. ME-TA carries the full AI governance surface and produces the audit evidence.
The AI stage calls the sponsor's own approved AI deployment — for example an Azure OpenAI or AWS Bedrock tenant operated by the sponsor, under the sponsor's identity provider. ME-TA operates none of the inference.
If your AI-usage policy permits only tools approved by your own IT, this election satisfies it by construction — the AI-inference sub-processor drops out of ME-TA's chain entirely.
Whenever AI is elected: a human reviews all AI-assisted output before anything returns to the sponsor, and the AI has no write access to sponsor systems — it drafts, humans decide. The elections apply equally to clinical trials and to clinical investigations / performance studies (MDR / IVDR).
Reading this page: the AI-specific detail — data categories, the AI-assisted workflow loop, and the operator-endpoint hardening profile — is collapsed by default in the purple ▸ panels below. If your engagement excludes AI, you can skip them entirely.
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.
The base engagement is four steps — deterministic and human-driven throughout. With an AI election in place, program development is augmented by the AI-assisted loop in the collapsed panel below; the data boundaries and the human review gate are identical in both.
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).
Human work in the WORK stage on the ME-TA-owned, BitLocker-encrypted operator PC — programs, specifications, drafts. Full data access by the engagement-assigned human; nothing leaves the intra-EEA chain.
The SAS programs run on the Statistical Computing Environment — validated, deterministic, no AI present. Full datasets are used here. Outputs and logs are produced.
The ME-TA data processor reviews the outputs in the WORK stage. Approved deliverables are returned to the sponsor through metawebservice.com.
With an AI election in place, the engagement runs as 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.
Election differences: under AI election B, step 3 (and step 6) run against the sponsor's own AI tenant instead of ME-TA's Bedrock path — everything else is identical. With no AI elected, this loop does not run at all; the four-step base workflow above is the whole engagement.
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. The AI stage and the Bedrock leg exist only when an AI election is in place (election A shown; under election B the inference target is the sponsor's own tenant; with no AI elected, those elements are absent and the diagram reduces to WORK ↔ SCE ↔ S3).
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. Controls are stated at design level — the named mechanism per boundary; the as-deployed evidence set for a specific engagement is produced at engagement time (same principle as the dated-snapshot note under the hardening profile below).
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) |
The AI-inference row is election-dependent. The Bedrock row above exists only under AI election A. Under sponsor-operated inference (AI election B) or the no-AI base service, the AI-inference row drops from the engagement's sub-processor chain entirely — the base chain is the infrastructure row plus ancillary business sub-processors.
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