.png)
The EU AI Act Is Now Real: What Technology Companies Need to Know
Artificial intelligence regulation in Europe is no longer something technology companies can treat as a future issue.
The EU AI Act entered into force in August 2024, and major portions of the framework are now applicable and enforceable. Since August 2, 2026, authorities have begun enforcing additional provisions, including transparency requirements for certain AI systems. Other requirements, particularly those governing specific high-risk systems, continue to phase in through 2027 and 2028.
For technology companies, the real question is no longer simply, "Does the AI Act affect us?"
It is:
Where does AI exist in our products, what role do we play in the AI value chain, and what controls should we build now?
This guide explains the EU AI Act for technology companies from a practical product, engineering, and governance perspective.
What Is the EU AI Act?
The EU Artificial Intelligence Act is a European Union regulation governing the development, deployment, distribution, and use of artificial intelligence systems.
Instead of regulating every AI system in exactly the same way, the Act uses a primarily risk-based framework.
The basic principle is straightforward:
The greater the potential impact of an AI system on people's safety or fundamental rights, the stronger the regulatory requirements.
The European Commission describes the framework as covering several broad levels of risk, ranging from minimal-risk applications to prohibited practices.
This matters because an AI-enabled spam filter does not present the same regulatory concerns as an AI system involved in employment decisions, biometric identification, education, critical infrastructure, or medical products.
The first job for a technology company is therefore not to create a generic "AI compliance policy."
It is to understand exactly what AI systems it develops, provides, integrates, or operates.
Why the EU AI Act Matters Outside Europe
A common misconception is that the EU AI Act matters only to companies headquartered inside the European Union.
That is too narrow.
Technology companies outside Europe can fall within the Act's scope when their AI systems or outputs enter the EU market or are used in ways covered by the regulation.
That makes the regulation particularly relevant to:
- SaaS vendors selling into Europe
- AI product companies
- mobile application developers
- cloud platforms
- enterprise software vendors
- IoT companies embedding AI in connected products
- data analytics companies
- HR technology vendors
- health technology companies
- generative AI providers
- companies integrating third-party AI models into their products
For a US, Indian, UK, or Asia-Pacific technology company, European market exposure therefore deserves review even if the company has no engineering office inside the EU.
A practical question to ask
Instead of asking:
"Are we an EU company?"
Ask:
"Can our AI system, service, model, or output affect users or customers in the EU?"
That question is much closer to the compliance problem technology leaders need to solve.
The First Mental Model: Understand Your Role
One of the easiest ways to misunderstand the EU AI Act is to focus only on the technology.
Regulatory responsibility also depends on the role your company plays.
You may be a:
- provider
- deployer
- importer
- distributor
- authorized representative
- provider of a general-purpose AI model
- downstream provider integrating another company's model
A company can potentially play different roles across different products.
For example, imagine a SaaS company using a third-party large language model.
The model developer may be the provider of the general-purpose AI model.
The SaaS company may then build an application around that model and provide the resulting AI system to enterprise customers.
Its responsibilities cannot automatically be transferred to the upstream model provider.
The AI Act also addresses responsibility across the AI value chain. In certain circumstances, parties modifying, rebranding, or substantially changing high-risk systems may take on provider responsibilities.
That makes supplier contracts, system architecture, documentation, and change management important parts of compliance.
Understand the Risk Categories
Technology companies should avoid treating every use of AI as equally regulated.
A better approach is to classify each AI use case.
Prohibited AI practices
Some AI practices are considered unacceptable because of the risks they create.
Examples addressed by the Act include certain uses involving manipulation, exploitation of vulnerabilities, social scoring, and certain predictive policing practices. The Commission began enforcing applicable prohibited-practice rules under the phased framework.
The practical implication is simple:
Before deciding how to comply with an AI feature, determine whether that use should exist at all.
High-risk AI systems
High-risk systems receive significantly more regulatory attention.
Relevant areas include certain AI applications involving:
- biometrics
- employment
- education
- critical infrastructure
- access to essential services
- migration and border control
- law enforcement
- regulated products
High-risk providers can face requirements involving risk management, technical documentation, logging, transparency, human oversight, conformity assessment, and quality management. Article 16, for example, sets out several provider obligations for high-risk systems.
These systems should therefore be designed differently from ordinary low-risk features.
Compliance cannot simply be added during the final release review.
Transparency-risk systems
Some AI systems trigger transparency obligations even when they are not classified as high-risk.
From August 2, 2026, Article 50 transparency requirements apply to certain systems. This includes requirements around informing people when they are interacting directly with AI and obligations relating to certain AI-generated or manipulated content.
For product teams, this can affect interface design directly.
A chatbot disclosure is no longer merely a UX choice in relevant situations.
It can be a regulatory requirement.
Minimal or limited regulatory exposure
Many everyday AI systems are not high-risk.
Examples can include applications such as spam filtering, recommendation features, internal productivity tools, or other low-impact AI functions, depending on how they are implemented and used.
That does not mean governance should disappear.
Security, privacy, reliability, contractual obligations, sector regulations, and customer expectations may still matter.
But companies should avoid building heavyweight compliance processes around every algorithm simply because it uses AI.
The key is proportionality.
How EU AI Act Compliance Should Work Inside a Technology Company
The strongest way to approach the Act is to convert regulatory requirements into an engineering workflow.
A useful lifecycle looks like this:
1. Discover AI usage
Create an inventory of AI across products and internal systems.
Include:
- machine learning models
- generative AI APIs
- recommendation engines
- automated scoring
- classification models
- computer vision
- predictive analytics
- biometric functions
- AI assistants
- AI features embedded in third-party SaaS products
Do not restrict the inventory to systems your team built from scratch.
Third-party AI matters too.
2. Define the intended purpose
The same technology can have very different risk profiles depending on how it is used.
A computer vision model counting warehouse boxes is very different from one evaluating employee behavior.
Document:
- what the system does
- who uses it
- who is affected by its output
- what decisions depend on it
- where it operates
- what data it processes
Intended purpose becomes an important anchor for risk classification.
3. Determine your role
Identify whether you are acting as provider, deployer, distributor, importer, or another regulated actor.
Also identify the upstream providers supporting your system.
For example:
Application
→ orchestration layer
→ third-party LLM
→ vector database
→ enterprise data
→ customer-facing output
That architecture may involve several parties with different responsibilities.
4. Classify risk
Determine whether the use case could fall under:
- prohibited practices
- high-risk AI
- transparency requirements
- general-purpose AI requirements
- lower-risk usage
Document why you reached that conclusion.
Do not rely on an informal verbal decision.
5. Map obligations to controls
Turn legal obligations into actual system controls.
These may include:
- logging
- documentation
- testing
- human review
- access controls
- monitoring
- model-version tracking
- incident management
- user disclosures
- synthetic-content marking
- supplier documentation
This is where compliance becomes operational.
6. Monitor change
AI systems evolve quickly.
Models change.
Prompts change.
Datasets change.
APIs change.
Product teams add new workflows.
A system that was initially low-risk may eventually be used for a more sensitive purpose.
Governance therefore needs a change-management process rather than a one-time certification exercise.
Tools and Stack Options for AI Act Readiness
There is no single "EU AI Act compliance platform" that solves the problem automatically.
Technology companies usually need several capabilities working together.
AI inventory and governance tools
These help organizations track:
- AI systems
- system owners
- models
- vendors
- use cases
- risk assessments
- approvals
- documentation
Smaller organizations may begin with structured internal documentation and workflow tools.
Larger companies may use dedicated AI governance platforms.
The important requirement is not the sophistication of the software.
It is whether the organization can answer:
What AI do we operate, who owns it, and what risks apply?
Model monitoring
Production AI systems should be observable.
Depending on the application, teams may monitor:
- model performance
- drift
- hallucination rates
- abnormal behavior
- safety violations
- latency
- failure rates
- human override events
For high-risk systems, logging and monitoring can become particularly important.
Model and prompt versioning
Generative AI systems introduce a new configuration problem.
A production system can change when you change:
- model version
- system prompt
- retrieval source
- temperature
- guardrails
- fine-tuning dataset
- orchestration logic
Versioning these elements helps teams reconstruct why an AI system behaved a particular way.
Audit logging
Traditional application logs often answer:
"Did the API request succeed?"
AI governance may need logs answering:
"Which model generated this output, using what input, which configuration, and what human action followed?"
These are very different questions.
Human oversight workflows
High-risk AI systems may require meaningful human oversight.
The regulation requires that appropriate human oversight be supported in relevant high-risk systems, with oversight measures proportionate to the context and risk.
This does not mean placing a human approval button beside every AI result.
Effective oversight requires the reviewer to have enough:
- context
- authority
- training
- information
- time
to intervene meaningfully.
A rubber-stamp review process is not effective oversight.
Best Practices for Technology Companies
Build an AI system register
Maintain one source of truth covering:
- system name
- owner
- business purpose
- users
- models
- vendors
- geography
- processed data
- risk level
- regulatory role
- approval status
- monitoring requirements
Without an inventory, AI governance quickly becomes fragmented.
Separate models from systems
Do not assume the risk of an application equals the risk of the underlying model.
A general-purpose model can power:
- a writing assistant
- a customer support bot
- a medical workflow
- a recruitment screening system
The same model can therefore appear inside systems with very different risk profiles.
Evaluate the complete use case.
Document decisions early
If your team concludes that a system is not high-risk, document the reasoning.
Do not wait until a customer or regulator asks.
Build transparency into UX
For relevant AI systems, disclosure should become a design requirement.
Since August 2, 2026, transparency obligations apply to certain interactive AI systems and certain AI-generated or manipulated content.
Product teams should therefore decide:
- where disclosure appears
- how clearly it appears
- whether machine-readable marking is required
- how generated content is identified
- whether users understand when AI is involved
Create vendor-review requirements
Third-party AI does not eliminate your risk.
Before integrating a model provider, consider requesting information covering:
- model documentation
- security
- data handling
- training-data policies
- evaluation practices
- version changes
- geographic processing
- incident notification
- contractual responsibilities
Include AI literacy in governance
AI literacy obligations began applying from February 2, 2025. The Commission identifies this as one of the provisions that became applicable earlier than the broader framework.
That means organizations should think beyond developer training.
Relevant employees may need enough understanding to use AI responsibly within their role.
This may include:
- product owners
- developers
- QA teams
- customer support
- sales teams
- compliance teams
- leadership
Common Pitfalls
"We only use an API, so the vendor handles compliance."
Not necessarily.
Your responsibilities depend on what your company builds and how the system is used.
"Our AI feature is small."
Regulatory exposure is driven more by use and impact than by engineering complexity.
A simple model used in a sensitive employment workflow can matter more than a technically sophisticated recommendation engine.
"We will classify everything after development."
Risk classification can affect architecture.
Waiting until release may force expensive redesign.
"Human oversight means someone can override the output."
The existence of an override button does not automatically create meaningful oversight.
The person needs competence, information, authority, and a practical opportunity to intervene.
"Documentation is a compliance-team task."
Engineering often holds the information needed to produce meaningful AI documentation.
Compliance teams cannot reconstruct:
- model behavior
- evaluation metrics
- input pipelines
- failure conditions
- model versions
- logging behavior
without technical involvement.
Performance, Cost, and Security Considerations
Compliance has an engineering cost.
But poor architecture makes that cost much higher.
Logging increases storage
Detailed AI logs can become large, particularly for systems processing high request volumes.
Teams should define:
- which events must be stored
- retention periods
- privacy requirements
- access controls
- whether prompts or outputs contain sensitive information
Logging everything indefinitely creates its own security and privacy risks.
Human review increases operating cost
Human oversight can increase:
- response time
- staffing requirements
- workflow complexity
That makes risk-based routing useful.
For example, a system may automatically process low-risk cases while escalating uncertain or sensitive outputs for human review.
AI governance can affect latency
Adding:
- safety checks
- moderation
- retrieval verification
- policy engines
- model routing
- logging
can increase application latency.
Teams should treat these components as part of the production architecture rather than external compliance layers.
Security remains essential
General-purpose AI providers with systemic risk face explicit cybersecurity and risk-management obligations under the Act.
For downstream technology companies, AI also introduces familiar security concerns in new forms:
- prompt injection
- unauthorized data exposure
- insecure model APIs
- poisoned retrieval sources
- excessive permissions
- sensitive prompt logging
- compromised plugins or agents
Compliance architecture and security architecture increasingly overlap.
If your AI product architecture is evolving faster than your governance model, it can help to review both together. Infolitz works with technology teams across AI, cloud, IoT, and application engineering to translate product requirements into practical technical controls.
What Changed in 2026?
The EU AI Act is being introduced through a phased timeline rather than one single implementation date.
Several dates matter.
February 2, 2025
Rules covering prohibited AI practices, definitions, and AI literacy began applying.
August 2, 2025
Governance provisions and obligations for providers of general-purpose AI models began applying.
August 2, 2026
This became a major operational milestone.
The Commission and national authorities began enforcing additional AI Act provisions, and Article 50 transparency requirements became applicable.
Relevant transparency rules include requirements concerning:
- direct interaction with AI
- certain deepfakes
- AI-generated or manipulated content
- machine-readable marking in applicable cases
December 2, 2027
Under the updated implementation framework following the AI Omnibus, rules for high-risk AI systems covered by Annex III are scheduled to apply from December 2, 2027.
August 2, 2028
Rules covering certain high-risk AI systems embedded in regulated products are scheduled to apply from August 2, 2028.
The important lesson is that "the AI Act deadline" is not one date.
Companies need a requirement-specific timeline.
What About General-Purpose AI and Generative AI?
Generative AI created one of the biggest challenges for the original risk model.
A general-purpose model can be used across thousands of downstream applications.
The AI Act therefore introduces separate requirements for providers of general-purpose AI models.
The obligations for GPAI providers began applying on August 2, 2025, with Commission enforcement powers applying from August 2, 2026. Models placed on the market before August 2, 2025 receive a later compliance date of August 2, 2027.
For providers of general-purpose AI models with systemic risk, additional requirements can include:
- model evaluations
- adversarial testing
- systemic-risk assessment
- incident reporting
- cybersecurity protections
These obligations are explicitly described in Article 55.
Most software companies, however, will not train frontier-scale general-purpose models themselves.
Their more common challenge will be understanding how responsibilities flow downstream when they build applications on top of those models.
Mini Case Study: An AI Support Platform
Consider a hypothetical SaaS company offering an AI customer-support platform to European enterprises.
The platform:
- integrates a third-party LLM
- retrieves information from customer documentation
- drafts support responses
- allows agents to approve or edit replies
- provides a customer-facing chatbot
At first glance, the company may think:
"The LLM provider owns the AI compliance problem."
That would be incomplete.
The SaaS company should still examine its own role and system.
Step 1: Inventory
The company identifies two separate AI functions:
- agent-assistance system
- customer-facing chatbot
Step 2: Intended purpose
The agent assistant drafts responses but does not automatically make legally significant decisions.
The chatbot interacts directly with customers.
Step 3: Transparency review
Because customers interact with an AI system directly, Article 50 transparency obligations may become relevant.
The UI should therefore be reviewed to ensure appropriate disclosure.
Step 4: Supplier review
The company documents:
- model provider
- model versions
- contractual terms
- security controls
- data-retention settings
Step 5: Logging
The team records:
- model version
- prompt configuration
- knowledge source
- generated answer
- whether an agent approved or modified it
Step 6: Monitoring
The team tracks:
- unsupported answers
- customer escalations
- unsafe responses
- retrieval failures
The result is not simply "legal compliance."
It is a more observable and governable AI product.
That is the larger opportunity hidden inside AI regulation.
EU AI Act vs GDPR
The AI Act does not replace the General Data Protection Regulation.
They solve different problems.
GDPR primarily governs personal-data processing.
The AI Act primarily governs risks associated with AI systems and models.
An AI system may therefore need to comply with:
- GDPR
- the AI Act
- cybersecurity requirements
- sector regulations
- consumer rules
- employment regulations
- product-safety rules
For example, an AI recruitment tool may raise both:
- personal-data questions under GDPR
- AI-system obligations under the AI Act
Technology leaders should therefore avoid creating an isolated "AI compliance silo."
AI governance should connect to privacy, security, product management, quality, and enterprise risk.
EU AI Act vs Traditional Software Compliance
Traditional software compliance often centers on questions such as:
- Was the application tested?
- Is customer data protected?
- Are access controls working?
- Can incidents be traced?
AI adds new questions:
- Why did the model produce this result?
- Which model version was active?
- What data influenced the output?
- Can a human challenge the decision?
- Has behavior drifted?
- Was the user informed AI was involved?
- Can generated content be identified?
- What happens when confidence is low?
These questions require closer coordination between engineering, product, legal, and operations.
That is why the EU AI Act should not be viewed simply as another privacy regulation.
It can influence how AI products are designed.
What Are the Penalties?
The potential penalties under the EU AI Act are significant.
For prohibited AI practices, fines can reach up to €35 million or 7% of worldwide annual turnover, depending on the circumstances and applicable thresholds.
Other violations can carry penalties of up to €15 million or 3% of worldwide annual turnover, while supplying incorrect or misleading information to authorities can trigger additional penalty levels.
The Act also provides proportional treatment in relevant cases involving smaller companies.
The larger business risk, however, may not always be the fine.
Technology companies may also face:
- delayed enterprise deals
- procurement objections
- product redesign
- market-access issues
- contractual disputes
- customer trust problems
Building governance early can therefore be less expensive than retrofitting it after enterprise adoption.
A Practical EU AI Act Readiness Checklist
Technology leaders can start with these questions:
- Do we know every AI system used across our products?
- Have we documented the intended purpose of each one?
- Do we know whether we are provider, deployer, or another regulated actor?
- Have we assessed whether any use is prohibited?
- Have we identified possible high-risk systems?
- Have we reviewed Article 50 transparency obligations?
- Do we know which general-purpose models we depend on?
- Can we identify model and prompt versions in production?
- Are important AI decisions logged?
- Can users tell when they are interacting with AI where required?
- Is human oversight meaningful?
- Do we evaluate third-party AI vendors?
- Do we monitor system behavior after deployment?
- Are AI-related incidents integrated into existing incident management?
- Do relevant employees receive AI literacy training?
- Can we explain why a system received its risk classification?
If several answers are "no," the organization probably has a governance gap rather than simply a documentation gap.
.png)
FAQs
What is the EU AI Act?
The EU AI Act is a European regulation establishing rules for developing, providing, deploying, and using artificial intelligence. It uses a risk-based framework with stronger requirements for higher-risk AI systems.
Is the EU AI Act already in effect?
Yes, but implementation is phased.
The Act entered into force in 2024. Some provisions applied from February 2025, GPAI obligations began applying in August 2025, and significant additional provisions, including transparency requirements, became applicable from August 2, 2026. Further high-risk requirements phase in later.
Does the EU AI Act affect US or Indian companies?
Potentially, yes.
Companies outside the EU should assess the regulation when their AI products, services, systems, or outputs enter the European market or affect covered users.
What is considered high-risk AI?
Certain AI uses involving areas such as biometrics, employment, education, critical infrastructure, migration, law enforcement, and regulated products can fall into high-risk categories depending on the exact application.
Does the EU AI Act apply to ChatGPT-style systems?
The Act includes provisions addressing general-purpose AI models and transparency requirements relevant to certain generative AI applications.
The exact obligation depends on whether a company provides the underlying model, builds a downstream AI system, or deploys that system.
Do chatbots need to disclose that they are AI?
In applicable cases, Article 50 requires people to be informed when they are interacting directly with an AI system unless that fact is obvious from the circumstances and context.
The transparency requirements became applicable from August 2, 2026.
Do we need to rebuild our AI architecture?
Not necessarily.
Many organizations can adapt existing systems by adding stronger:
- inventory
- logging
- documentation
- monitoring
- human oversight
- disclosure
- model governance
The architecture changes required depend on the use case and classification.
Does using a third-party AI model remove our responsibility?
No.
Using an external model provider may change your role and obligations, but downstream applications still need their own assessment.
What should CTOs do first?
Start with an AI inventory.
You cannot classify, govern, monitor, or document systems you have not identified.
Then map each system to its intended purpose, users, regulatory role, risk category, and required controls.
The EU AI Act is not just a legal requirement. It is becoming a product, engineering, and governance requirement
Conclusion
The EU AI Act changes the way technology companies need to think about AI. Compliance is no longer something that can be added after a product has been designed and deployed. Teams need to understand where AI exists, how each system is used, what level of risk it creates, and which technical controls are required.
For most companies, the practical starting point is simple: build an AI inventory, define the intended purpose of each system, classify the risk, identify your role in the AI value chain, and connect regulatory obligations to real engineering controls such as logging, monitoring, transparency, human oversight, and change management.
The companies that approach AI governance as part of product architecture rather than a separate compliance exercise will be better positioned to adapt as the regulatory landscape continues to evolve.
Building or integrating AI into your products?
The EU AI Act increasingly connects regulatory requirements with product architecture, data flows, monitoring, security, and AI governance.
Talk to Infolitz Software about building AI systems with practical governance and technical controls designed in from the start.
