Mistral gives you an EU-native model. It does not give you EU-compliant deployment. SWT3 bridges the gap between choosing the right provider and proving you govern the output.
v0.7.8 PREVIEW – Mistral adapter ships with v0.7.8. Supports chat.complete(), chat.stream(), and chat.complete_async(). Available on PyPI and npm at release.
Who this is for: European enterprises deploying Mistral models, compliance officers navigating EU AI Act GPAI obligations, platform teams integrating Mistral via API or self-hosted weights, and procurement teams evaluating sovereign AI options.
GPAI provider obligations became enforceable August 2, 2025. High-risk deployer obligations apply from August 2, 2026. Mistral signed all three chapters of the GPAI Code of Practice and meets its obligations as a provider. But the EU AI Act draws a sharp line between provider and deployer. Your obligations as a deployer exist independently of Mistral's compliance as a provider. Non-conformity: up to 35M EUR or 7% of worldwide annual turnover.
The EU AI Act creates two distinct categories of obligation for general-purpose AI:
| Party | Who | Obligations | Status |
|---|---|---|---|
| GPAI Provider | Mistral AI (Paris) | Art. 53: technical documentation, copyright policy, transparency info to downstream deployers | Signed Code of Practice. EU-based. Compliant. |
| Deployer | You | Art. 26: risk management, data governance, transparency, human oversight, accuracy, cybersecurity, logging | Your responsibility. Cannot be delegated. |
Mistral publishes model cards, provides system prompt documentation, and maintains training data policies. That satisfies their obligations under Article 53. It does not generate a single byte of evidence for your obligations under Article 26.
This is the line. Everything upstream of the API call is Mistral's responsibility. Everything downstream -- how you use the model, what decisions it informs, how you monitor its behavior -- is yours. SWT3 operates on your side of this line, generating continuous evidence of responsible deployment.
EU data residency. Mistral is the only frontier-class provider headquartered in the EU. Data processed via La Plateforme stays in EU infrastructure. No US CLOUD Act exposure. No adequacy decision dependency.
Downloadable weights. Mistral models (Mistral Large, Codestral, Mistral NeMo) are available for self-hosting. You control the compute, the data never leaves your infrastructure, and you can verify the exact model weights running in production.
Direct AI Office relationship. As an EU entity, Mistral deals directly with the AI Office without needing an authorized representative. Incident reporting, model evaluations, and systemic risk assessments flow through EU governance structures.
GPAI Code of Practice signatory. Mistral signed all three chapters: transparency, copyright, and systemic risk. This is the strongest public commitment to GPAI compliance from any frontier model provider.
Evidence of your deployment behavior. Proof that your application used the model responsibly. Audit trails of model decisions in your context. Documentation that your guardrails were active. These are deployer obligations. Mistral cannot fulfill them for you because they depend on how you use the model, not how the model was built.
When you call client.chat.complete(model="mistral-large-latest", ...), you become a deployer. These obligations activate:
SWT3 generates the evidence that satisfies the logging, monitoring, and technical measures requirements. Every inference call produces a witness anchor. Every anchor is a verifiable compliance artifact.
The Mistral adapter intercepts chat.complete(), chat.stream(), and chat.complete_async() transparently. Your application code does not change.
from mistralai import Mistral
from swt3_ai import Witness
from swt3_ai.adapters.mistral import wrap_mistral
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
tenant_id="YOUR_TENANT",
jurisdiction="FR", # Mistral's jurisdiction
legal_basis="EU-AI-ACT", # Deployer's legal basis
)
client = Mistral(api_key="your-mistral-key")
witnessed = wrap_mistral(client, witness)
# Identical to unwrapped usage
response = witnessed.chat.complete(
model="mistral-large-latest",
messages=[
{"role": "system", "content": "You are a financial advisor."},
{"role": "user", "content": "Analyze this portfolio risk."},
],
)
# response is untouched -- same object, same fields
print(response.choices[0].message.content)
witness.flush()import { Mistral } from '@mistralai/mistralai';
import { Witness } from '@tenova/swt3-ai';
import { wrapMistral } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://your-instance.example.com/api/v1/witness',
apiKey: 'axm_your_key',
tenantId: 'YOUR_TENANT',
jurisdiction: 'FR',
legalBasis: 'EU-AI-ACT',
});
const client = new Mistral({ apiKey: 'your-mistral-key' });
const witnessed = wrapMistral(client, witness);
const response = await witnessed.chat.complete({
model: 'mistral-large-latest',
messages: [
{ role: 'system', content: 'You are a financial advisor.' },
{ role: 'user', content: 'Analyze this portfolio risk.' },
],
});
console.log(response.choices[0].message.content);
await witness.flush();Model alias resolution. When you request mistral-large-latest, the response contains the actual model ID (e.g., mistral-large-2411). The SWT3 adapter captures the resolved model ID, not the alias. This means your compliance record always reflects the exact model version that generated the response, even when the alias rotates.
model_id: Resolved model version (e.g., mistral-large-2411), not the alias. prompt_hash: SHA-256 of all message content. response_hash: SHA-256 of the generated text. system_prompt_hash: Separate hash of the system instruction.
Query anchors for provider="mistral" and group by model_id. If the organization claims they use mistral-large-latest, the anchors should show a single resolved version during stable periods, with clean transitions when Mistral rotates the alias. Multiple concurrent model versions for the same deployment suggest either A/B testing (which should be documented) or configuration inconsistency (which is a finding).
Streaming responses are accumulated transparently. The adapter collects text fragments and token usage from stream events, then mints a single anchor when the stream completes.
# Python streaming
stream = witnessed.chat.stream(
model="mistral-large-latest",
messages=[{"role": "user", "content": "Explain quantum computing"}],
)
for chunk in stream:
# Each chunk is delivered to your code immediately
delta = chunk.data.choices[0].delta.content
if delta:
print(delta, end="", flush=True)
# Anchor minted automatically when stream ends// TypeScript streaming
const stream = await witnessed.chat.stream({
model: 'mistral-large-latest',
messages: [{ role: 'user', content: 'Explain quantum computing' }],
});
for await (const chunk of stream) {
const delta = chunk.data?.choices?.[0]?.delta?.content;
if (delta) process.stdout.write(delta);
}
// Anchor minted automatically when stream completesYour streaming UX is unaffected. Tokens arrive at the same speed. The witness anchor is minted after the last chunk, capturing the complete response hash, total latency, and final token counts.
When Mistral updates mistral-large-latest to point at a new version, the model hash in your witness anchors changes. This is automatic drift detection:
model_id: mistral-large-2411, model_hash: a7f3...model_id: mistral-large-2502, model_hash: 9c1e...Any monitoring system watching your SWT3 anchors immediately detects the version change. No Mistral-specific integration required. The evidence is structural.
System prompt drift detection. The adapter separately hashes your system prompt. If someone modifies the system prompt in production, the system_prompt_hash changes in subsequent anchors. You can detect both model drift and instruction drift from the same evidence stream.
Request a time-series export of model_hash and system_prompt_hash values for the assessment period. Plot both on a timeline. Model hash transitions should correlate with Mistral's published version rotation dates. System prompt hash should be constant unless a change was authorized. Any system_prompt_hash change without a corresponding change request record is an unauthorized instruction modification -- a control failure under Art. 26(1).
Verify anchor density matches the organization's stated inference volume. Request total inference count from application metrics and compare against anchor count in the ledger for the same period. A ratio below 0.95 means some inferences are not being witnessed. Check for gaps longer than 1 hour during business hours -- these indicate the witness pipeline was down or bypassed. For Art. 26(5) compliance, the logging must be automatic, not selective.
If you run Mistral models on your own infrastructure (via vLLM, Ollama, or TGI), the inference never leaves your network. SWT3 adapters work identically:
| Serving Stack | Adapter | Notes |
|---|---|---|
| Mistral API (La Plateforme) | wrap_mistral |
Native Mistral SDK. Model alias resolution. |
| vLLM serving Mistral weights | wrap_vllm |
OpenAI-compatible. Model hash from local weights. |
| Ollama running Mistral | wrap_ollama |
Auto-detected from OpenAI client base URL. |
| AWS Bedrock (Mistral models) | wrap_bedrock |
Via InvokeModel/Converse API. |
Same evidence format regardless of serving stack. An auditor verifying your compliance does not need to know where the model runs. They verify the witness anchor, which is infrastructure-independent.
Each Mistral inference anchor maps to specific deployer obligations:
| Obligation | Article | Evidence from SWT3 Anchor |
|---|---|---|
| Operation logging | Art. 26(5) | model_id + prompt_hash + response_hash + timestamp |
| Model identification | Art. 53 (downstream) | model_id resolves alias to actual version |
| Behavior monitoring | Art. 26(2) | model_hash changes on version rotation (drift detection) |
| Instruction integrity | Art. 26(1) | system_prompt_hash detects unauthorized prompt changes |
| Performance monitoring | Art. 26(2) | latency_ms + input_tokens + output_tokens |
| Refusal tracking | Art. 14 (oversight) | has_refusal flags non-standard finish reasons |
| Jurisdiction binding | Art. 26 | jurisdiction + legal_basis stamped on every anchor |
Step 1: You choose Mistral because it is EU-native, weights are available, and the provider signed the Code of Practice. This is a procurement decision.
Step 2: You deploy Mistral with SWT3 witnessing. Every inference generates a fingerprinted anchor. This is a technical measure.
Step 3: Your anchors accumulate into a continuous evidence stream. Model version changes are detected. System prompt modifications are flagged. Refusals are tracked. This is ongoing monitoring.
Step 4: An auditor, regulator, or data subject requests evidence. You export your anchors. Each one is independently verifiable. This is accountability.
Choosing the right model provider is step one. Proving you govern the deployment is everything after. Mistral handles step one. SWT3 handles everything after. Together, you have a complete EU AI Act compliance story -- provider obligations covered by Mistral, deployer obligations covered by continuous witness evidence.
# Python
pip install swt3-ai mistralai
# TypeScript
npm install @tenova/swt3-ai @mistralai/mistralaifrom mistralai import Mistral
from swt3_ai import Witness
from swt3_ai.adapters.mistral import wrap_mistral
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
tenant_id="YOUR_TENANT",
jurisdiction="FR",
legal_basis="EU-AI-ACT",
)
client = Mistral(api_key="your-key")
witnessed = wrap_mistral(client, witness) # This is the only new line
# Every call now generates a witness anchor
response = witnessed.chat.complete(
model="mistral-large-latest",
messages=[{"role": "user", "content": "Summarize this contract clause"}],
)
witness.flush()