Claude for a law firm, compliant by design

The lawyers wanted to use Claude. The problem was not the model, it was everything around it: where the data goes, who sees it, how long it stays, who did what. We built a perimeter where the answer to each of these questions is written into the configuration, not into a promise.

The client

A professional association of lawyers (name withheld) practising civil, commercial and employment law, with partners, associates, trainee lawyers and support staff who work every day on pleadings, contracts, legal opinions and client correspondence.

By definition, this material contains the most sensitive kind of data a firm handles: information covered by professional secrecy, personal data of clients and opposing parties, often health data (personal injury and employment cases) and criminal-offence data.

The brief

The firm had a very common problem: AI was already in, but through the wrong door. Some professionals were using chatbots on personal accounts, pasting in excerpts from pleadings and contracts. No data processing agreement between the firm and the provider, no control over where those texts ended up, no way to revoke access when an associate left the firm, no record of what had been shared.

Banning it did not work: the benefits for drafting, summarising case files and reviewing contracts were too obvious. So the brief was clear: give everyone Claude, but inside a perimeter where every legal obligation is met and can be demonstrated.

The requirements, put in writing with the partners and the DPO:

• no client data retained by the model provider, nor used to train it;
• processing only within the European Union;
• every user individually identified, no shared credentials;
• personal data minimised before it reaches the model;
• separation between matters, to respect conflicts of interest and internal confidentiality;
• traceability of who uses the system, without creating a new archive of confidential content;
• enough documentation for the DPIA, the record of processing activities and the client privacy notice.

Why AWS Bedrock

We chose to deliver Claude through Amazon Bedrock for four concrete reasons:

1. The contract is already the right one. Processing is covered by the AWS Data Processing Addendum (incorporated into the Service Terms, with standard contractual clauses), and through AWS Artifact AWS provides the ISO 27001, 27017, 27018 and 27701 certifications and the SOC reports needed for the DPIA.
2. Bedrock does not retain prompts and responses. By design, request content is neither stored nor used to train models, and Anthropic, as the model provider, has no access to prompts and responses.
3. European regions. Inference can be restricted to data centres in the European Union.
4. Every control in one place. Identity, private networking, encryption with your own keys, audit and organisation policies are native AWS services, configurable as code and verifiable at any time.

The rest of the work was turning these premises into a locked-down configuration, because a compliant service used badly is still non-compliant processing.

The architecture at a glance

Layer	Choice	Goal
Model	Claude on Amazon Bedrock, eu. inference profiles	No retention, processing in the EU
Identity	IAM Identity Center federated with the firm's identity provider, MFA	Individual accounts, centralised revocation
Minimisation	Pseudonymisation layer + Bedrock Guardrails	The model sees as little as possible
Network	Private VPC endpoints (PrivateLink), no public access	Traffic never crosses the internet
Encryption	AWS KMS with keys managed by the firm	Key control over all data at rest
Documents	Bedrock Knowledge Bases with per-matter filters	Ethical walls between case files
Audit	Immutable CloudTrail + metadata-only application audit	Who, when, what, never the content
Governance	AWS Organizations, SCP, AWS Config, infrastructure as code	Nobody can switch the controls off

1. Zero data retention: what really happens to the data

"Zero retention" is a promise that is easy to break. It is not enough for the model to keep nothing: every point in the chain where a piece of text could end up written down somewhere has to be closed.

• On the Bedrock side. Prompts and responses are processed and not stored by the service, do not train any model and are not accessible to the model provider.
• Model invocation logging switched off. Bedrock can record full prompts and responses to CloudWatch or S3. Useful in development, dangerous in production. We switched it off and prohibited re-enabling it with a Service Control Policy: not even an account administrator can do it.
• Prompt caching. Bedrock's prompt cache is temporary (minutes) and not persistent: it cuts cost and latency on long documents without creating an archive.
• No history by default in the application. Conversations live in the session. Saving them is an explicit user choice, tied to a matter, encrypted and subject to automatic deletion on expiry (TTL) according to the period set in the DPIA.
• No content in application logs. Backend logs are filtered: they record technical identifiers, timings and error codes, never the text. Every log group has a retention period set, no "keep forever".
• No data in the browser. The interface does not store conversations in localStorage or the browser cache, so a laptop left open or shared does not become an archive.
• Features that move data outside the perimeter are disabled. No web search, no tools calling external services, no third-party marketplace models, no fine-tuning (which would require retaining training data).

2. Data residency: everything in the European Union

• European regions. The account runs from an EU region. Claude is invoked through eu. cross-region inference profiles, which spread the load across European regions only.
• Global profiles prohibited. global. profiles can route requests to any region in the world: they are blocked at organisation level.
• Non-European regions blocked. An SCP denies any operation outside EU regions (with only the technical exceptions for global services such as IAM).
• Everything else follows. The S3 document buckets, vector index, KMS keys, audit trails and backups all sit in the same European regions.

An excerpt of the organisation policies applied to the account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalInferenceProfiles",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:*:*:inference-profile/global.*"
    },
    {
      "Sid": "DenyInvocationLoggingChanges",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutModelInvocationLoggingConfiguration",
        "bedrock:DeleteModelInvocationLoggingConfiguration"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBedrockApiKeys",
      "Effect": "Deny",
      "Action": ["iam:CreateServiceSpecificCredential", "bedrock:CallWithBearerToken"],
      "Resource": "*"
    }
  ]
}

3. Individual accounts, no shared keys

The most common mistake in corporate AI projects is a single API key pasted into a config file and used by everyone. In a law firm, that means not knowing who sent what, and not being able to remove one person's access without removing everyone's.

• Single sign-on with the firm's identity provider. Users sign in with the same credentials they use for email and documents, through federated IAM Identity Center. MFA is mandatory.
• Automatic provisioning (SCIM). When an associate leaves the firm, they are deactivated in one place and lose access everywhere, at the same moment.
• No IAM users, no long-lived access keys. Temporary credentials only. Creating IAM users, access keys and Bedrock API keys is prohibited via SCP.
• Role-based permissions. Partners, lawyers, trainees and support staff have different profiles: which models they can use, which document collections they can query, who can save conversations.
• Least privilege for the application too. The backend can only invoke approved models and inference profiles, and only with the firm's guardrail applied.
• Root account secured. Hardware MFA, no operational use, documented break-glass procedure.

4. Personal data and professional secrecy: minimise before the model

The safest data is the data the model never receives. For most tasks (summarising a contract, checking a clause, outlining a brief) the model does not need to know the client's name.

Reversible pseudonymisation. Before every call, an application layer running in the firm's account replaces identifiers with consistent placeholders: [PERSONA_1], [SOCIETA_2], [CF_1]. Names, Italian tax codes (codice fiscale), VAT numbers, IBANs, email addresses, phone numbers, addresses, licence plates, court docket numbers. The mapping table lives only in memory for the duration of the request and is used to rebuild the response: the lawyer reads the text with the real names, the model never saw them.

When a task genuinely needs the real data (for example, the final draft of a pleading), the user can switch pseudonymisation off for that request: the choice is deliberate and recorded in the audit log.

Bedrock Guardrails as a second line of defence. On top of pseudonymisation, a guardrail applied to both input and output:

• sensitive information filters that mask or block the recognised PII types;
• custom regular expressions for Italian formats, where generic automatic detection is less reliable: codice fiscale, VAT number (partita IVA), Italian IBAN, court docket numbers (numeri di RG);
• prompt attack filter, important because users upload third-party documents that may contain hidden instructions (prompt injection);
• grounding check on answers based on the firm's documents, to reduce responses that the sources do not support.

The guardrail is not optional: the IAM policy denies any model invocation that does not include the firm's guardrail, using the bedrock:GuardrailIdentifier condition key.

An example of the pattern used for the codice fiscale:

\b[A-Z]{6}[0-9LMNPQRSTUV]{2}[ABCDEHLMPRST][0-9LMNPQRSTUV]{2}[A-Z][0-9LMNPQRSTUV]{3}[A-Z]\b

Special categories and criminal-offence data. Processing involving health data (GDPR art. 9) and data relating to criminal convictions and offences (GDPR art. 10) was mapped separately in the DPIA, with specific usage rules.

5. Private network and encryption

• Nothing crosses the internet. Calls to Bedrock, S3 and KMS go through VPC interface endpoints (AWS PrivateLink). The application runs in private subnets.
• Credentials are useless outside the perimeter. Policies only allow Bedrock to be invoked through the firm's private endpoint (the aws:SourceVpce condition): even a stolen credential will not work from outside.
• Encryption in transit with TLS 1.2 or higher, with unencrypted requests rejected at bucket level (aws:SecureTransport).
• Encryption at rest with the firm's own keys. Documents, vector index, saved conversations, logs and trails are encrypted with customer managed KMS keys, with automatic rotation and key policies that separate those who administer the keys from those who use them. Revoking a key makes the data unreadable.
• Block public access enabled at account level on all S3 buckets.
• External Key Store option. For the strictest requirements, the architecture is ready to keep keys on an HSM outside AWS (XKS), assessed in the transfer impact analysis.

6. The firm's documents and ethical walls

The real value arrives when Claude can work on the firm's own documents: pleading templates, past opinions, standard contracts, case law collected over the years.

• Bedrock Knowledge Bases on S3 buckets in the EU, with a multilingual embedding model running on Bedrock in the EU and an encrypted vector index.
• Metadata on every document: matter, client, assigned team, confidentiality level.
• Ethical walls enforced server-side. Every search is filtered by the user's groups as read from the SSO identity, not from the text of the question. A lawyer who is not assigned to a matter cannot retrieve its documents, even by asking for them explicitly. It is the same principle the firm uses to manage conflicts of interest and internal confidentiality, carried over into the AI system.
• Sources cited in every answer, with a link to the original document, so verification is immediate.
• Consistent deletion. When a document is deleted or a case file archived, synchronisation removes it from the index as well. Retention rules follow those of the case file.

7. Traceability without storing content

The firm needs to be able to answer "who used the system, when and on which matter" without creating a second archive of confidential data.

• AWS CloudTrail at organisation level, across all regions, with log file integrity validation and storage in a separate log account on buckets with Object Lock (cannot be modified or deleted for the defined period).
• Metadata-only application audit: user, time, model, matter, token count, any guardrail intervention (the type, not the text), pseudonymisation being switched off.
• Continuous configuration monitoring with AWS Config, Security Hub and GuardDuty: if anyone tries to enable content logging, create a long-lived key, disable CloudTrail or open up a bucket, an alert fires.
• Costs allocated by practice area through tagged application inference profiles, which also show who is really using the tool.

8. Account governance and Rayo's role

• AWS Organizations with separate accounts for the AI workload, logs and security: whoever administers the application cannot touch the audit logs.
• The account belongs to the firm. Rayo operates through a cross-account role with time-limited, approved and logged access. Rayo has no access to conversation content or documents.
• Rayo as data processor under a GDPR art. 28 agreement, for technical management activities only.
• Infrastructure as code. The whole configuration is versioned and reviewable: every change has an author, a date and a reason, and the environment can be rebuilt identically.
• Budgets and quotas with alert thresholds, to avoid billing surprises and spot unusual usage.

9. The regulatory framework, point by point

Regulation	Obligation	How it is covered
GDPR art. 5 and 25	Minimisation, privacy by design and by default	Pseudonymisation, zero retention, history off by default
GDPR art. 28	Contracts with processors	AWS DPA, art. 28 agreement with Rayo
GDPR art. 30	Record of processing activities	Dedicated entry for the AI assistant, with purposes, data categories and measures
GDPR art. 32	Security of processing	Encryption, MFA, least privilege, private network, monitoring
GDPR art. 33 and 34	Data breach management	Automatic alerts and a notification procedure within 72 hours
GDPR art. 35	Impact assessment	Full DPIA, with the technical measures documented
GDPR art. 9 and 10	Health and criminal-offence data	Dedicated usage rules and stronger controls
GDPR chapter V	Transfers outside the EU	Processing in the EU, Data Privacy Framework and standard clauses, transfer impact assessment
Italian Code of Conduct for Lawyers (Codice deontologico forense), art. 28	Confidentiality and professional secrecy	Closed perimeter, ethical walls between matters, no access for the model provider
Italian Law 132/2025, art. 13	AI in the intellectual professions only as support, with information to the client	Outputs always marked as drafts, clause in the letter of engagement, client privacy notice
AI Act, art. 4	AI literacy	Mandatory training for all users before activation
AI Act, classification	Risk level assessment	Support use documented as not high-risk, reassessed for every new use case

10. What technology cannot do on its own

A perfect configuration is not enough if the people using it do not know what they are doing. The project also included:

• Internal usage policy: what can be entered, when to switch off pseudonymisation, how to verify sources, what must never be delegated.
• Training for partners, associates, trainees and support staff: hallucinations, checking citations, prompt injection risks in third-party documents.
• Mandatory human oversight. Every output is a draft. The signature and the responsibility remain the lawyer's, as the law requires.
• Client privacy notice and a clause in the letter of engagement explaining in plain terms which AI tools are used and with what safeguards.
• Periodic review of the configuration and the DPIA with every new model or new feature.

The full checklist

Everything we verified before giving access to the first user:

Data and retention

• Model invocation logging switched off and blocked via SCP
• No history by default, TTL on saved conversations
• Application logs without content, retention set on every log group
• No data stored in the browser
• Web search, external tools, marketplace and fine-tuning disabled

Residency

• Only eu. inference profiles, global. profiles prohibited
• SCP denying non-EU regions
• S3, vector index, KMS, logs and backups in the EU

Identity

• SSO with the firm's identity provider and mandatory MFA
• Automatic provisioning and deprovisioning via SCIM
• No IAM users, no long-lived access keys, Bedrock API keys prohibited
• Role-based permissions and least privilege for the application
• Root account protected with hardware MFA

Minimisation

• Reversible pseudonymisation before the model
• Mandatory guardrail on input and output, enforced via IAM
• Custom patterns for codice fiscale, VAT number, IBAN and court docket numbers
• Prompt attack filter and grounding check

Network and encryption

• PrivateLink for Bedrock, S3 and KMS
• Invocation allowed only from the private endpoint
• TLS mandatory, S3 public access blocked
• KMS keys managed by the firm with automatic rotation

Documents

• Metadata by matter, client, team and confidentiality
• Server-side access filters based on the SSO identity
• Source citations and synchronised deletion

Audit and governance

• Organisation-wide CloudTrail with Object Lock in a separate account
• Metadata-only application audit
• AWS Config, Security Hub and GuardDuty with alerts
• Infrastructure as code, budgets and quotas
• Rayo access time-limited, logged and with no visibility of content

Documentation and people

• DPIA, record of processing activities, transfer analysis
• Art. 28 agreement with Rayo
• Internal usage policy and training under art. 4 of the AI Act
• Client privacy notice and clause in the letter of engagement

Results

• An end to "shadow" AI. Personal accounts were retired: the whole firm uses a single tool, under the firm's control.
• Demonstrable compliance. Every obligation maps to a precise configuration, verifiable and documented in the DPIA. If the Italian Data Protection Authority (Garante) or a client asks "where does my data go?", the answer is a page, not a reassurance.
• No new archive of confidential data. The system produces drafts, summaries and reviews, and keeps nothing beyond what the firm has decided.
• Instant revocation. An associate who leaves loses access the moment their company account is deactivated.
• Controls that cannot be bypassed. The most important protections are enforced at organisation level: they do not depend on the goodwill of whoever administers the account.

Tech stack

Area	Technologies
Model	Claude on Amazon Bedrock (EU inference profiles)
Identity	AWS IAM Identity Center, federated SSO, SCIM, MFA
Data protection	Custom pseudonymisation layer, Amazon Bedrock Guardrails
Documents	Amazon Bedrock Knowledge Bases, Amazon S3, encrypted vector index
Network	Amazon VPC, AWS PrivateLink
Encryption	AWS KMS with customer managed keys
Audit and security	AWS CloudTrail, S3 Object Lock, AWS Config, Security Hub, GuardDuty
Governance	AWS Organizations, Service Control Policies, infrastructure as code

In short

Using Claude compliantly in a law firm does not mean giving up the best model, it means building the right perimeter around it. Zero retention, data in the EU, individual identities, minimisation, encryption with your own keys, ethical walls and audit: none of these on its own is enough. Together, they turn a powerful AI into a tool a firm can use on real case files, and defend in front of anyone who asks for an account of it.