We just wanted to add an AI chatbot...
That is usually how it starts.
Someone suggests adding AI to customer support.
Someone else wants AI-generated content.
The product team experiments with automatic ticket classification.
Recruiting wants AI-powered candidate screening.
Marketing wants faster content creation.
A week later there is a prototype.
A month later there is a feature.
A few months later someone asks:
"Wait... does the EU AI Act affect us?"
The short answer:
Probably.
The slightly longer answer:
Much earlier than most teams expect.
The AI Act is not just for OpenAI and Google
Many teams assume the AI Act only applies to large AI companies.
That would be convenient.
It is also wrong.
The AI Act does not only look at who builds AI models.
It also looks at who uses them.
And that's where many companies suddenly find themselves part of the conversation.
You do not need to train your own large language model.
You do not need a team of AI researchers.
You do not need your own datacenter.
If your product uses AI to support decisions, generate content, classify people or automate processes, you should at least understand what responsibilities come with it.
Most teams are not building AI
They are building products.
And that distinction matters.
A lot of product teams don't wake up in the morning thinking:
"Let's create an AI system."
Instead they think:
- Let's improve support response times.
- Let's automate repetitive work.
- Let's make onboarding easier.
- Let's help recruiters process applications faster.
- Let's generate content more efficiently.
The goal is usually business value.
AI is just the tool.
Unfortunately, regulators care about the tool as well.
The first question: What is the AI actually doing?
Not all AI systems are treated equally.
The AI Act follows a risk-based approach.
Some use cases are considered low risk.
Others require significantly more attention.
A simple example:
Using AI to generate draft blog posts?
Usually lower risk.
Using AI to evaluate job applicants?
Very different conversation.
One affects content production.
The other can directly influence people's opportunities and livelihoods.
The more an AI system influences important decisions about people, the more attention regulators expect.
The danger zone is often closer than expected
Many teams accidentally move into higher-risk territory.
Not because they have bad intentions.
Because the feature sounds useful.
Consider these examples:
Customer Support
Low risk:
- AI summarises tickets
- AI suggests responses
Potentially problematic:
- AI automatically makes binding decisions
- AI rejects customer requests without oversight
Recruiting
Low risk:
- AI helps write job descriptions
- AI summarises interview notes
Higher risk:
- AI scores candidates
- AI ranks applicants
- AI recommends hiring decisions
Internal Tools
Low risk:
- AI organises documents
- AI generates meeting summaries
Potentially problematic:
- AI evaluates employee performance
- AI influences promotions
- AI determines disciplinary actions
The difference is often not technical.
It is about impact.
"But we're only using ChatGPT"
This is one of the most common misconceptions.
Using an external AI provider does not automatically transfer responsibility.
If an AI-powered feature becomes part of your product or business process, your responsibilities do not magically disappear because someone else trained the model.
Think of it like cloud hosting.
Running your application on a cloud provider does not remove your responsibility for security.
Using an AI provider does not remove your responsibility for how AI is used.
Product teams need a new habit
For years we have asked questions like:
- Is this technically feasible?
- Is this valuable?
- Is this usable?
- Is this secure?
Now there is another question:
Is this AI use case appropriate?
Not every problem should be solved with AI.
Not every workflow benefits from automation.
Not every decision should be delegated to a model.
Good product teams already know this instinctively.
The AI Act simply forces us to think about it more explicitly.
The practical checklist
Before adding AI to a product, ask:
1. Does the AI influence decisions about people?
Hiring.
Promotion.
Education.
Healthcare.
Financial decisions.
If yes, slow down and investigate further.
2. Is there meaningful human oversight?
Can a human review, override or challenge the output?
Or is the AI effectively making the decision?
3. Would users expect AI to be involved?
Transparency matters.
People should not have to guess.
4. Could the output cause harm if it is wrong?
Every AI system makes mistakes.
The question is not whether mistakes happen.
The question is what happens when they do.
5. Can you explain how the feature works?
Not the model internals.
The product behaviour.
If you cannot explain it to a customer, you probably need to understand it better yourself.
The biggest mistake is waiting too long
Most compliance problems are surprisingly cheap to prevent.
They become expensive when they are discovered after launch.
The teams that struggle most are usually not reckless.
They simply treat compliance as something to think about later.
The teams that succeed ask the uncomfortable questions early.
Not because lawyers told them to.
Because it helps them build better products.
The AI Act is really about trust
When people hear regulation, they often think about paperwork.
But underneath the legal language, the AI Act is trying to solve a simple problem:
How do we create trust in AI systems?
Customers want to know when AI is involved.
Employees want fair treatment.
Users want transparency.
Companies want innovation without unnecessary risk.
Those goals are not enemies.
In fact, they are surprisingly aligned.
The best AI products are rarely the ones that automate the most.
They are the ones that earn the most trust.
And trust has always been a product problem long before it became a regulatory one.
At BitBitHooray, we love building with AI. But we believe responsible AI starts long before compliance audits and legal reviews. It starts with asking better questions when designing products. Because the fastest way to ship an AI feature is not always the smartest way to build one.
