The structural problem of AI regulation can be summed up in one sentence: the law relies on predictability, while AI generates effects no one has yet seen at the time regulations are written. The AI Act attempts to address this issue, without fully resolving it.
What is ethical debt in the context of AI
#Ethical debt is the gap between what technology can already do and what society has managed to reflect on, regulate, and safeguard against misuse. This concept is analogous to technical debt in software engineering: shortcuts taken now yield quick results but accumulate costs that someone will eventually pay.
In the case of AI, ethical debt grows for several reasons simultaneously. First, innovation cycles are shorter than legislative cycles. A European regulation takes an average of three to five years from the Commission’s proposal to entry into force. A language model undergoes a new generation every year or two. Second, side effects of AI systems often remain hidden until large-scale deployment. Bias in a recruitment model reveals itself after thousands of decisions, not just one.
At Cashcrown, we observe this pattern with every deployment: a company wants to automate a process that looks low-risk on paper, only to discover during an audit that the training data contains discriminatory patterns inherited from past human decisions. Ethical debt isn’t virtual. It’s in the data.
AI Act 2026: what it changes, what it doesn’t
#The AI Act entered into force in August 2024. In 2025, bans on unacceptable-risk systems and transparency requirements for GPAI models began to apply. The binding deadline for the full requirements on high-risk systems in Annex III remains August 2026. Under the simplification package (Digital Omnibus), the Commission has proposed postponing this deadline to December 2, 2027—but until it is adopted by the Parliament and Council, the binding date stays August 2026, so companies should plan their compliance for that deadline. This is the world’s first attempt to regulate AI through a risk-based lens, rather than by technology type.
Key logic of the AI Act: the higher the risk to fundamental rights and safety, the stricter the requirements.
| Risk Level | Example Systems | Main Requirements |
|---|---|---|
| Unacceptable | Social scoring, subliminal manipulation | Prohibition of use |
| High (Annex III) | Recruitment, credit, medical diagnostics, infrastructure management | EU AI Act DB registry, conformity assessment, technical documentation, human-oversight, event logs |
| Limited | Chatbots, deepfakes | Obligation to disclose AI interaction |
| Minimal | Spam filters, AI games | No additional requirements |
What the AI Act doesn’t resolve: it doesn’t define how to measure model bias in specific research contexts. It doesn’t specify who is liable when an AI system in a supply chain fails during inference. And it doesn’t answer how to regulate a model that learns post-deployment, altering its behavior in ways unforeseen by its creators.
Here, AI governance becomes a practical tool, not just a legal concept: a company or research institution must have its own AI management processes because regulation alone isn’t enough.
Three categories of ethical problems the law doesn’t solve on its own
#Bias inherited from data.
A model trained on historical data replicates historical injustices. A credit risk assessment algorithm trained on data from 1990–2010 may inevitably favor demographic groups that had better access to credit at the time—not because it’s flawed, but because the data is.
The regulatory solution (a bias audit requirement for high-risk systems) is necessary but insufficient. The law states that an audit must take place. It doesn’t specify who conducts it, what tools to use, or how to interpret results in a domain-specific context. That decision remains with the researcher or system engineer.
In practice, we see companies asking, “Did our model pass the audit?” instead of asking, “Does our model work fairly for every user subgroup?” The first answer complies with the law. The second is ethical.
Explainability and the right to an explanation.
Explainability is the technical ability to explain why a model made a given decision. GDPR Article 22 guarantees the right not to be subject to solely automated decisions and the right to request human review. The AI Act extends these requirements for high-risk systems.
The problem is that regulatory “explainability” (documentation that the system was audited) differs from operational explainability (the user understands why the system rejected their application). The most effective models, like deep neural networks, are often the hardest to explain in terms a layperson can grasp.
At Cashcrown, for every decision-making system we deploy for clients, we implement an explanation layer: the model generates a decision, a separate component generates a natural-language justification, and human-oversight verifies consistency before delivery to the user. This isn’t an AI Act requirement for all systems, but we consider it the ethical minimum for any system affecting human decisions.
Liability in the AI supply chain.
Who is liable when an AI system built by Company A, deployed by Company B, and used by Company C harms a user? The AI Act introduces a division between providers and deployers, but supply chains are often longer: the base model comes from one provider, the adaptation layer from another, and deployment is handled by a third. Liability is diffused across the chain. Regulation is only beginning to address this. In the meantime, ethical decisions are made by specific individuals in specific companies.
The role of human-oversight: not just a legal requirement
#Human-oversight in the context of the AI Act is a requirement for high-risk systems. In the context of research and deployment ethics, it’s more: it’s a design decision that determines where humans remain accountable for outcomes.
The pattern we use in analytical agent deployments distinguishes three types of control points:
| Control Point | Example in Research and Deployments | Decision-Maker |
|---|---|---|
| Input Validation | Training data passed bias audit | Data steward |
| Hypothesis/Result Verification | Model shortlisted candidates; HR approves the list before invitations | Department manager |
| Irreversible Decision | Credit denial, contract termination, clinical diagnosis | Authorized human |
Automation bias—the tendency to accept automated system outputs without critical review—is a real psychological phenomenon. The faster and more confident the system, the stronger the temptation to skip verification. A well-designed human-gate doesn’t slow the process. It protects against this specific error.
GDPR, DPIA, and AI: where obligations intersect
#GDPR and the AI Act are two separate regulations with partially overlapping requirements. GDPR governs personal data. The AI Act governs AI systems. In practice, most AI systems process personal data, so both apply simultaneously.
DPIA (Data Protection Impact Assessment) is mandatory when personal data processing may pose a high risk to individuals’ rights. For AI systems meeting the AI Act’s high-risk criteria, a DPIA is practically always required.
Key intersection points:
- Large-scale automated profiling (GDPR Art. 22 + AI Act high-risk classification)
- Sensitive data in model training (GDPR Art. 9 + AI Act data governance requirements)
- Right to erasure vs. vectors in a knowledge base (GDPR Art. 17 + no clear mechanism in the AI Act)
The last point remains open. If personal data entered a model as part of the training set, deleting it from the raw database doesn’t remove its influence on the model’s weights. Regulation doesn’t resolve this. System architecture does: RAG systems with a separate knowledge base allow document removal without model retraining. This is a design choice with ethical consequences.
How companies and research institutions should manage ethical debt
#Ethical debt doesn’t disappear with the passage of a law. It’s reduced through conscious design decisions, processes, and organizational culture. Based on deployments we’ve observed, several practical layers can be identified:
AI system registry. Every AI system used in an organization should be cataloged: purpose, training data, user population, risk level per the AI Act, responsible person. Without a registry, there’s no governance.
Bias audit before deployment. Not certification, but structured questions: Where does the training set come from? Which groups are overrepresented? What were the historical decisions in this data, and do we want to perpetuate them?
Documenting system limits. Every AI system has a certainty threshold. Beyond this, the response should go to a human, not the end user. Defining this threshold before deployment is an ethical decision, not just a technical one.
Post-deployment review. AI systems drift. Input data changes. Model behavior after six months in production may differ from test behavior. Regular reviews of results for systematic anomalies are part of responsible deployment.
For more on organizing data governance for AI, see the article on data governance for AI, and for identifying risks in decision-making systems, see the article on the black box problem.
FAQ
#Is the AI Act already in force in 2026?
#Partially. Bans on unacceptable-risk systems took effect in February 2025. Providers of general-purpose AI models (GPAI) have had transparency obligations since August 2025. Under the Digital Omnibus package, the Commission has proposed postponing the full requirements for high-risk systems (Annex III) from August 2026 to December 2, 2027; the proposal has not yet been adopted, so the binding deadline remains August 2026, and that is the date to prepare for. Companies deploying AI systems should check whether their use cases qualify as high-risk and, if so, begin preparing technical documentation and conformity assessments well in advance.
How to distinguish a high-risk AI system from others?
#The AI Act defines high-risk systems via Annex III: this includes recruitment, credit scoring, biometric systems, critical infrastructure management, decisions affecting access to public services, medical diagnostic systems influencing treatment, and several other categories. If a system processes personal data and affects decisions with significant consequences for a person’s life, employment, or finances, it’s likely high-risk. When in doubt, it’s safer to conduct a DPIA and consult with a DPO.
Is AI explainability technically achievable?
#Partially. Methods like SHAP, LIME, and attention maps provide local explanations: why the model made this specific decision for this specific input. Global explanation of the entire model—understood as a full account of every decision—is unattainable for deep neural networks. Good practice is to design systems where a local explanation is automatically generated for each decision and available to the user upon request, especially in high-risk systems.
What are the consequences of violating the AI Act?
#Penalties follow a structure similar to GDPR: up to €35 million or 7% of global annual turnover for violations involving unacceptable-risk systems, up to €15 million or 3% for other violations. For GPAI systems, up to €15 million or 3% of turnover. The European AI Office oversees GPAI models, while national supervisory authorities enforce the remaining provisions.
How to start organizing AI ethics in a company with a limited budget?
#Not by buying a tool. By asking three questions about every AI system already in use: (1) Who is responsible for this system’s outcomes? (2) What training data was used, and where did it come from? (3) What happens when the system makes a mistake? The answers to these three questions reveal more ethical gaps than most formal audits. The articles on responsible innovation and the role of humans in the loop expand on these themes in the context of specific deployments.
The topic of AI regulation is inextricably linked to the question of how LLMs generate hypotheses in research practice. If you’re deploying an AI system in your organization and want to assess where your ethical processes stand, the readiness assessment tool helps identify gaps before an incident occurs.
