Employees route prompts through dozens of foundation models across ChatGPT, Claude, Gemini, open-weight deployments, and embedded vendor features. Without a written policy, teams guess which models may process customer data, whether fine-tuning is allowed, and who owns compliance when a GPAI provider updates training practices. Legal and security reviews stall while engineering ships integrations through personal API keys.
A foundation model usage policy defines approved models and versions, data class rules per tier, constraints on fine-tuning and retrieval-augmented generation, GPAI provider versus deployer responsibilities, and exception workflows for pilots. This guide gives compliance and platform owners copy-ready policy sections aligned to EU AI Act Article 53 GPAI obligations for teams operating AI API integrations and AI automation workflows.
Approved Model Registry and Version Pinning
Every foundation model available for enterprise use must appear in an approved registry with provider name, model ID, pinned version, hosting region, risk tier, and approval date. Silent model upgrades by SaaS vendors change capability and safety profiles without procurement notice. Version pinning is a control, not a preference: production systems reference explicit model strings, and changes require re-approval.
| Registry field | Purpose | Policy rule |
|---|---|---|
| Model identifier | Exact API model string or deployment name | No unlisted model strings in production |
| Version pin | Snapshot date or semantic version | Auto-upgrade disabled without change ticket |
| Hosting region | Data residency and subprocessors | EU data stays in approved EU endpoints |
| Risk tier | Maps to data class permissions below | Tier mismatch blocks API key issuance |
| GPAI provider status | Article 53 obligations on vendor | Require Annex XII downstream docs before approval |
Deprecation and Sunset
When providers deprecate models, policy requires migration plans within vendor notice windows and prohibits new projects on sunset models. Link registry entries to your AI inventory register and change management gates.
Open-Weight Registry Entries
Open-weight models need separate registry entries with checksum verification, license terms, and internal hosting approval even when EU AI Act documentation exemptions apply to the upstream provider. Your organization remains deployer for use-case risk.
Data Classes Allowed Per Model Tier
Map organizational data classes (public, internal, confidential, regulated PII, special category) to model tiers with explicit allow, deny, or conditional rules. A tier-one vendor-hosted frontier model approved for internal summaries is not automatically approved for HIPAA PHI or financial records. Policy language should be enforceable through API gateway rules and DLP integrations, not honor system alone.
| Data class | Tier 1 (frontier SaaS) | Tier 2 (enterprise contract) | Tier 3 (self-hosted) |
|---|---|---|---|
| Public marketing copy | Allowed | Allowed | Allowed |
| Internal business data | Conditional: zero-retention DPA required | Allowed with logging | Allowed |
| Customer PII | Denied unless named exception | Conditional: DPIA and BAA/DPA | Allowed with controls |
| Special category (health, biometric) | Denied by default | Exception only with legal sign-off | Conditional: isolated environment |
Prompt Minimization Requirements
Policy requires data minimization in prompts: send the smallest text segment needed, redact identifiers where possible, and prohibit bulk exports of databases into chat interfaces. Pair with technical controls on AI API payload size and field-level tokenization.
Logging and Retention
Define what prompt and completion logging is permitted per tier, retention periods, and access roles. Logging aids security investigations but creates new data stores subject to privacy law.
Fine-Tuning and RAG Constraints
Fine-tuning, adapter training, and retrieval-augmented generation that sends organizational data to model providers require separate approval paths with dataset inventories, consent checks, and prohibition on special category data unless explicitly authorized. RAG is not inherently safer than fine-tuning: indexed documents can leak through retrieval or poison vector stores. Policy must cover both.
- Fine-tuning: approved datasets only, no customer PII without legal review, versioned training snapshots.
- RAG: document classification before indexing, access controls on vector stores, periodic re-index audits.
- Feedback loops: user corrections used for training require opt-in and anonymization standards.
- Prohibited: training on production secrets, credentials, or unreleased financial data.
- Required: delete derived weights when vendor contract ends or model is decommissioned.
Automation Workflow Boundaries
AI automation that chains foundation models across multiple steps must inherit the strictest data class rule from any step in the chain. Document orchestration patterns in architecture reviews before production enablement.
Evaluation Before Customization
Require baseline evaluation on held-out data before and after fine-tuning or RAG deployment; policy blocks customization when regression exceeds defined thresholds on safety or accuracy metrics. Store evaluation reports as policy evidence attachments.
GPAI Provider vs Deployer Responsibilities
The EU AI Act distinguishes GPAI model providers (Article 53) from deployers who integrate models into AI systems; your policy must assign obligations to each party and forbid assumptions that vendor compliance covers your use case. From August 2025, GPAI providers must maintain Annex XI technical documentation, supply Annex XII information to downstream integrators, maintain copyright compliance policies, and publish training content summaries. Deployers remain responsible for how models are used in your products and internal workflows.
| Obligation area | GPAI provider | Your organization (deployer) |
|---|---|---|
| Technical documentation | Annex XI to authorities; Annex XII to integrators | Collect, archive, map to your risk assessments |
| Copyright and training data | Policy and public training summary per Article 53 | Evaluate sufficiency for your legal exposure |
| Acceptable use | Provider acceptable use policies | Internal use policy aligned and stricter where needed |
| Systemic risk (if applicable) | Article 55 evaluations and mitigations | Downstream impact assessment for your deployment |
| Incident reporting | Serious incidents per provider obligations | Your incident process for customer and regulator notice |
Contract Clauses
Procurement must require GPAI providers to deliver Annex XII integration information, model change notification, and subprocessors list updates as contractual deliverables linked to registry approval. Open-source GPAI models may qualify for documentation exemptions unless classified as systemic risk; your policy still requires internal due diligence.
Multi-Vendor Routing
When applications route prompts across multiple foundation model providers, policy requires each provider in the routing table to meet the data class tier for that traffic split. Fallback models must not silently downgrade to unapproved endpoints.
Exception and Pilot Approval Workflow
Pilots and policy exceptions require a written request with business justification, data classes involved, duration, success criteria, and named risk owner approval from security, privacy, and legal for high-risk cases. Time-boxed pilots prevent permanent shadow configurations. Exception registers feed quarterly governance council review.
- Employee or team submits exception form with use case and proposed model.
- Automated check against registry and data class matrix.
- Security and privacy review for confidential or regulated data.
- Legal review when GPAI provider terms conflict with internal policy.
- Time-boxed approval with mandatory end date and decommission plan.
- Post-pilot decision: promote to registry, extend with justification, or shut down.
Pilot Data Handling
Pilots must use synthetic or minimized datasets unless explicit approval covers production data classes. Label pilot systems in your inventory register as exception status until promoted.
Revocation Triggers
Revoke model approval immediately on provider breach notification, failed red team findings, or DPA termination. Policy defines communication paths to affected teams within 24 hours of revocation.
Enforcement and Attestation
Enforce policy through API key vaults, SSO-gated vendor consoles, CI/CD checks on model strings, and quarterly attestation by business owners that their teams comply. Technical enforcement beats policy PDFs alone. Pair blocks with an approved-tool catalog employees can access faster than personal accounts.
Training Requirements
Annual acceptable use training must cover approved models, prohibited data classes, and exception request paths. Track completion rates as a governance KPI.
Audit Evidence
Maintain policy version history, registry exports, exception register, and sample API gateway deny logs for auditor sampling. Evidence demonstrates operational policy, not shelf-ware.
Cross-Border Teams
Global teams must route prompts only through registry endpoints approved for each employee region; policy prohibits EU employees from using US-only model deployments for internal confidential data. Document regional endpoint mappings in the registry and enforce via geolocation-aware API routing rules.
Frequently Asked Questions
How do we handle open-weight foundation models?
Treat open-weight models as internal deployments: require security review of weights provenance, license compliance, hosting isolation, and full deployer obligations regardless of upstream GPAI exemptions. Open weights do not eliminate governance; they shift hosting and patching responsibility to your team.
What about bring-your-own-model (BYOM) from individual teams?
BYOM is prohibited in production unless the model passes registry approval, hosting meets tier requirements, and a named owner accepts deployer liability. Personal experimentation on non-production data may be allowed in sandbox environments defined in policy.
Can we use multi-vendor routers that switch models automatically?
Multi-vendor routers are permitted only when every candidate endpoint appears in the approved registry and routing logic enforces data class rules per destination. Log routing decisions for audit and block fallback to consumer-tier endpoints.
Do consumer ChatGPT accounts fall under this policy?
Consumer accounts processing company data violate policy unless covered by an approved enterprise agreement with DPA and registry entry. Shadow consumer use is a discovery and remediation problem, not a policy exception.
Implementation Roadmap
Week one: draft policy sections and inventory current models; week two through four: build registry and data class matrix; month two: deploy API enforcement and exception workflow; ongoing: quarterly registry attestation and GPAI documentation refresh. Start with models processing the highest data sensitivity, then expand coverage. Legal should review GPAI crosswalk before publication.
Conclusion
A foundation model usage policy succeeds when approved models are version-pinned in a registry, data classes map to enforceable tiers, fine-tuning and RAG face explicit constraints, GPAI provider and deployer roles are documented with EU AI Act alignment, and exceptions follow time-boxed approval workflows. Platform and compliance teams who publish clear rules and back them with technical controls reduce both regulatory exposure and ad hoc model sprawl.
