EU AI Act: what dev teams should document for AI features now

Since the AI Act entered the rollout phase, AI compliance is no longer a topic only large model providers have to care about. Teams that add AI features to websites, SaaS products, internal tools, or agency projects now sit in a longer supply chain: model provider, API provider, own application, customer data, logging, support workflows, and often third-party automations.

The good news: most small teams are not providers of a general-purpose AI model themselves. The inconvenient news: they still need to explain which model they use, what it is used for, which data flows into it, and which risks the feature creates.

What changed around GPAI

The European Commission published the General-Purpose AI Code of Practice on 10 July 2025. It is designed to help providers of general-purpose AI models meet AI Act obligations around safety, transparency, and copyright. The Commission describes the Code as a voluntary tool; providers that sign and follow it can use it to demonstrate compliance with the corresponding AI Act obligations more easily.

The GPAI rules have applied since 2 August 2025. Enforcement by the AI Office starts one year later for new models and two years later for models already placed on the market before that date. That may sound distant, but it already matters for product teams: model choices, vendor decisions, and architecture decisions made today shape how explainable a project will be in 2026 and 2027.

What this means for software projects

If a project uses chatbots, text generation, automated summaries, code assistants, classification, or agentic workflows, the team should not wait until a customer asks for documentation. A small, maintained AI file inside the project is the practical move.

It should cover at least these points:

• Purpose of the AI feature: What should the feature do — and what is explicitly out of scope?
• Model and provider: Which model, which API, which region, which contractual settings?
• Data flows: Which personal data, customer data, logs, or files are sent to the provider?
• Storage and logging: Are prompts, outputs, files, or metadata stored?
• Human oversight: Where does a human review results before users or customers rely on them?
• Fallbacks: What happens if the AI returns a wrong, unsafe, or empty answer?
• Sources and rights: Are contents generated, copied, summarized, or processed from external sources?

This is not bureaucracy for its own sake. It protects the team from the classic horror scene: the feature is live, a customer asks about privacy and the AI Act, and everyone looks at each other like episode 8 right before the season finale.

Privacy is still the second boss fight

The AI Act does not replace the GDPR. If personal data enters prompts, the project still needs a valid legal basis, transparent information, processor agreements, sensible deletion concepts, and technical safeguards.

Three areas are especially sensitive in AI features:

1. Prompt contents: Users often enter more data than the interface expects.
2. Support and admin tools: Internal teams quickly paste customer data into AI assistants when no clear rule exists.
3. Logs and analytics: Debugging matters, but raw prompts can contain sensitive data.

For website operators and small SaaS teams, the sentence “we use AI” is not enough. A better product decision is: which data may enter the AI system, which data may not, and how is that technically enforced?

Practical start: an AI feature checklist

Before launching a new AI feature, run a short review:

• Is the feature’s purpose explained clearly in the product and privacy information?
• Is the provider and model documented?
• Is personal data minimized or masked?
• Is there a clear line between assistance and automated decision-making?
• Can users recognize when AI is involved?
• Are prompts, system instructions, and failure modes versioned?
• Are there tests for hallucinations, prompt injection, and data leaks?

Teams that document this early do not have to reconstruct everything later from Git history, Slack threads, and dangerously tired memories.

Conclusion

The AI Act usually does not hit small development teams as model providers, but it absolutely affects them as deployers and integrators of AI systems. The best immediate step is not an 80-page policy. It is clean technical documentation: model, purpose, data flow, oversight, risks, and fallbacks.

That does not only make AI features more robust from a regulatory perspective. It also makes them easier to maintain, safer, and easier to explain — exactly what production software needs anyway.

Sources

• European Commission: The General-Purpose AI Code of Practice
• European Commission: General-Purpose AI Code of Practice now available
• Regulation (EU) 2024/1689, Artificial Intelligence Act
• Le Monde: First measures of European AI Act regulation take effect

Note: This article is a technical overview and does not constitute legal advice.