Governance · PiniShv

100 Days to the EU AI Act Deadline. Your Engineering Team Hasn't Started.

Fri, 24 Apr 2026 16:00:00 +0300

Today is April 24, 2026. The EU AI Act’s enforcement deadline for high-risk AI systems is August 2, 2026. That’s exactly 100 days.

In most engineering organizations, the legal team is tracking this. The compliance team is tracking this. The engineering team has not been formally told what they need to ship by August.

By July, that gap will not be recoverable. Not because the work is impossible. Because the work requires sprint capacity that wasn’t planned for.

Who this actually applies to
#

Before anything else, kill the myth that this is “a European company problem.”

The EU AI Act applies extraterritorially. If your AI system is used by EU citizens, you are in scope regardless of where your company is headquartered. US-based SaaS with EU customers? In scope. Israeli startup selling to a German bank? In scope. AI feature in a product that’s accessible from Europe at all? In scope. Your B2B API is called by someone else’s product that serves EU users? Still in scope. Downstream distribution doesn’t insulate upstream providers.

There’s no “I didn’t know” exemption. Fines go up to €35 million or 7% of global annual revenue, whichever is higher.

If you have any customer traffic from the EU, even indirect traffic through a partner, this is your problem.

What the law actually requires (in engineering language)
#

Each critical article, translated into changes in your repo.

Article 50: Transparency
#

Law: Users must be told when they’re interacting with an AI. AI-generated content needs machine-readable markers and metadata.

Engineering translation:

Add a visible UI disclosure anywhere users interact with an AI-driven feature. Not buried in the terms of service. In the flow.
Attach machine-readable metadata (HTTP headers, EXIF-equivalent content tags) to any AI-generated content your system produces or distributes.
For chat interfaces, a persistent “AI assistant” label near the input field is the minimum.

What this means for your sprint: audit every product surface where a model output reaches a user. Every single one. Add disclosure if missing. Add metadata tagging if content leaves your system.

Article 12: Record-keeping
#

Law: Every interaction with a high-risk AI system must be logged in a structured, auditable format that a regulator can query.

Engineering translation:

Structured event logging on every model inference. Inputs, outputs, model version, timestamp, user or tenant identifier, confidence scores if available.
The log must be queryable. A 12-month pile of unstructured stdout does not count.
Retention needs to match the regulatory requirement (typically 6 years for high-risk systems).

What this means: if your current AI feature logs to stdout or to a generic app log, that’s not compliant. You need a dedicated audit trail with a proper schema, proper indexing, and retention guarantees.

What this costs: this is the one that eats the most sprint time. Log schema design, storage tier pricing, indexing for query performance, access controls on the audit store. If you’re starting in April for an August deadline, you’re already tight.

Article 14: Human oversight
#

Law: Sensitive AI decisions need a defined path for human review before taking effect.

Engineering translation:

Identify the decision points where AI output influences high-risk outcomes (hiring, credit, healthcare, legal, education, critical infrastructure).
At each of those points, there must be a deterministic path that routes the decision to a human before the outcome is final.
The human must have the actual ability to override the AI’s suggestion, not just acknowledge it. “Click to confirm” with no real friction doesn’t count.

What this means: your AI features that auto-approve, auto-reject, or auto-route need a human gate if the outcome is classified high-risk. The gate has to be real, with a real UI, real authority, and real training for the humans using it.

Article 5: Prohibited practices
#

Law: Some AI uses are outright banned. Social scoring of individuals by public authorities, exploitative manipulation of vulnerabilities, certain biometric categorization, real-time remote biometric ID in public spaces.

Engineering translation:

Content policy filters on inputs before they reach your models.
A classification layer that recognizes and blocks prohibited use patterns.
Documentation showing how you prevent your system from being used for prohibited purposes.

What this means: for most engineering teams, this is the smallest implementation lift, unless you’re in a directly affected industry (HR tech, surveillance, credit scoring, biometrics). The documentation burden is still real. Auditors will ask for your prohibited-use risk assessment even when your answer is “we don’t do any of this.” “We don’t do that” is an answer that requires evidence, not a shrug.

Why the legal team isn’t the bottleneck
#

The legal teams have been on this for a year. The compliance frameworks exist. The consultants are getting 20 to 30% of the budget pie for certification-related work. Vendors are already passing costs through with visible markups.

None of that ships code.

The bottleneck is engineering sprint capacity that was never allocated. Specifically:

Audit log infrastructure (Article 12) is an engineering-heavy build
Human oversight UIs (Article 14) need product and front-end work
AI feature disclosure (Article 50) needs coordinated UX across every surface
API inventory and risk classification (prerequisite for all of it) requires engineering time to map

In organizations doing this well, someone senior on the engineering side already took the brief from legal and translated it into specific issues in the backlog before the end of Q1 2026. If that hasn’t happened in your org yet, somebody needs to do it this week.

The 100-day plan
#

Here’s the realistic minimum. Compress if you have less time. Don’t expand if you have more, because you don’t.

Days 1 to 15 (now through May 9): Inventory and triage
#

Complete API inventory of every AI-involved endpoint your systems call, produce, or expose.
Classify each endpoint by risk level under the Act (minimal, limited, high-risk, prohibited).
Name an engineering owner for each high-risk surface. Not the CTO. An actual engineer who’s going to do the work.

If you do nothing else in the next two weeks, do this. Everything else depends on it.

Days 16 to 50 (May 10 through June 13): Build the audit layer
#

Design and ship a structured event logging system for high-risk AI interactions.
Retention policy, schema, indexing, access controls. All of it.
Backfill where you have data. Don’t backfill where you don’t, but document the gap.

This is where your engineering budget goes. If you’re outsourcing one thing, outsource the rest so engineering can focus here.

Days 51 to 80 (June 14 through July 13): Disclosure and oversight
#

Add AI disclosures across every relevant product surface.
Add machine-readable metadata to AI-generated content.
Ship the human oversight UIs for high-risk decision points.

This is where product and design need to stop saying “it doesn’t affect this quarter’s roadmap.” It does now.

Days 81 to 100 (July 14 through August 2): Documentation and dry-runs
#

Complete the technical documentation required for your risk classification.
Run internal dry-runs of a regulator query. Can you actually produce the audit trail for a specific user’s specific interaction from four months ago? If not, fix it now.
Train the humans doing the oversight role. They need to understand what they’re reviewing.

The one thing that blows up the plan
#

If you’re an engineering leader reading this in April, you have time. If you’re reading this in July, you don’t. The honest answer at that point is to either pull high-risk AI features off your EU-facing product or accept that your first enforcement cycle will go badly. Better said out loud now.

What to do this week
#

Three things, in order.

Monday morning: one-hour sync between your most senior engineer and your most senior compliance person. Leave with a shared doc listing every AI-involved product surface. Share with the CTO or VP Eng by end of day.

By Thursday: classify every surface (minimal, limited, high-risk, prohibited). For high-risk ones, name an engineering owner.

By Friday: the audit-log infrastructure team exists and knows what they’re building. Even if it’s two people. Even if one of them is borrowed from a platform team. The work starts now or it doesn’t finish.

The EU AI Act isn’t a future problem anymore. It’s a planning problem you have this week. It’s also where the longstanding gap between how fast organizations produce AI code and how slowly they govern it finally gets priced. In fines. In front of regulators. Most orgs will not realize that until too late. The ones that do now get to ship on time.

If you’re already working on this, I’d love to hear what’s surprised you. If you haven’t started, forward this to whoever decides sprint priorities. Find me on X, Telegram, or LinkedIn.

Disclaimer: This article references the EU AI Act and related compliance materials for illustrative and educational purposes. It is not legal advice. You should consult a qualified legal team for compliance specifics in your jurisdiction and industry. Articles, deadlines, and classifications referenced are based on publicly available sources at the time of writing and may change. The opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any specific compliance vendor mentioned. This is commentary, not legal, investment, or business advice.

AI Makes Code Cheap to Produce. Not Cheap to Own.

Thu, 02 Apr 2026 12:00:00 +0200

Here’s the gap that should worry engineering leaders more than any single AI incident.

AI made code dramatically cheaper to produce. Boilerplate, scaffolding, internal tools, glue code, first-pass implementations. All faster. I’ve written about this before and I believe the speed is real.

But the cost of owning code didn’t drop at the same rate. Some of those things got faster too. CI pipelines, SAST, dependency scanning, automated testing. The tooling exists. But having the tools and actually making them the focus are different things. Most teams automate the easy checks and skip the hard ones. And when code volume doubles, even the automated parts need more attention than they’re getting.

The gap between production speed and ownership capacity is where organizations get hurt.

What the data says
#

Sonar’s developer survey puts numbers on it: 72% of developers who have tried AI use it daily. AI accounts for 42% of committed code. But 96% don’t fully trust the output, and only 48% say they always verify AI-assisted code before committing.

Half the code isn’t being verified by the people who committed it. That’s not a tooling problem. That’s a discipline gap.

On the security side, Veracode found risky security flaws in 45% of tests across more than 100 models. Georgetown CSET found that almost half of AI-generated snippets contained bugs that were often impactful. GitGuardian’s 2026 report detected 28.6 million new secrets in public GitHub commits in 2025, a 34% increase year over year, with AI-assisted commits leaking secrets at roughly twice the baseline.

On code quality, GitClear’s analysis found more cloned code, less refactoring, and more short-term churn. A January 2026 study on autonomous coding agents found static-analysis warnings rising 18% and cognitive complexity up 39%.

None of this says AI is useless. All of it says code production is accelerating faster than code governance.

Where it breaks
#

The pattern I keep seeing looks the same across organizations.

AI generates code quickly. The PR looks good. The tests pass (if there are tests). The review is fast because the diff is large and the reviewer is busy. It ships. It works. For now.

Three months later, someone needs to modify that code and can’t understand it because nobody on the team wrote it in a way they’d naturally reason about. Or a dependency it pulled in has a vulnerability. Or a license obligation nobody noticed is now a legal question. Or the secrets it embedded are in a log somewhere.

The cost doesn’t show up at generation time. It shows up at ownership time. And by then, the team that generated it has moved on to the next sprint.

DORA’s 2025 AI report found a negative relationship between higher AI adoption and delivery stability. Their recommendation is one of the oldest engineering lessons: small batch sizes. AI can generate massive blocks of code that are hard to review and test. Small batches plus strong automated testing are the counterweight.

What to change
#

Same gates for all code. AI-generated code goes through tests, review, linting, SAST, dependency scanning, secret scanning, and license checks. No exceptions. The standard is “would we be comfortable owning this in production?”

Small batches, always. Resist the temptation to let AI generate a 500-line PR. Break it up. Review it in pieces. The speed gain from generation is worthless if it creates a review and maintenance bottleneck downstream.

Track provenance. If you can’t answer what third-party components entered through AI, what licenses apply, and who owns the output, you don’t understand what you shipped.

Measure ownership, not output. Escaped defects. Rework rate. Time-to-understand for someone new. Rollback frequency. These tell you whether code is owned, not just produced.

Budget for the ownership layer. If your team is spending 80% of its capacity generating code and 20% on everything else, flip that conversation. The generation is the cheap part now. The ownership is where the investment needs to go.

The one-line version
#

AI made the first draft cheap. It didn’t make the second year cheap. Plan accordingly.

How is your team handling the gap between code production speed and governance capacity? I’d love to hear what’s working. Find me on X or Telegram.

'I Only Built a Small Script for Myself.' That Might Be the Most Dangerous Sentence in Your Company.

Thu, 02 Apr 2026 10:00:00 +0200

“I only built a small local script for myself.”

That sentence, from a well-intentioned engineer who just wanted to automate something tedious, might be the most dangerous thing happening inside your organization right now.

Not because the engineer is malicious. Because AI changed what one person can do in an afternoon. And the organization’s controls weren’t built for that.

The old version of this problem
#

Shadow IT has been around forever. Someone signs up for a SaaS tool with their personal email. A team spins up an AWS instance outside the approved account. A developer installs an unsanctioned browser extension. IT security has been playing whack-a-mole with this for decades.

But the old version had natural friction. Building useful software took time. One person couldn’t do that much damage alone because one person couldn’t build that much alone.

AI removed that friction.

What shadow AI actually looks like
#

An engineer uses their personal Claude or ChatGPT account to build an internal tool. They don’t think of it as shadow AI. They think of it as being productive. The tool works. It saves the team time. Everyone’s happy.

But that tool may touch production credentials. It may pull in five packages nobody approved. It may embed an API key. It may process customer data. It may send data to an AI provider through a personal account with consumer-grade privacy terms. It never goes through SAST, SCA, secret scanning, license review, or architecture review.

Sonar’s developer survey says 35% of developers access AI coding tools through personal accounts rather than work-sanctioned ones. GitHub’s code scanning analyzes code in a repository. If the code never makes it to a repository, those controls are blind.

One person. One afternoon. Zero oversight. And because AI made them productive enough to actually ship something useful, nobody questions it until something breaks.

Why this is different from old shadow IT
#

The old shadow IT problem was someone using Dropbox instead of SharePoint. Annoying, but contained.

Shadow AI is someone building a tool that connects to production databases, processes customer records, calls external APIs, and runs on a schedule. In a day. Without anyone knowing.

The blast radius is completely different. And the speed means it happens before governance can react.

I wrote about the Claude Code leak this week. That was a packaging mistake at Anthropic. But the shadow AI version of that story plays out in organizations every day. Not as a public incident. As a quiet accumulation of unmanaged code touching systems the company is responsible for.

What to actually do about it
#

Sanction the tools, not just the behavior. Give teams approved AI accounts with enterprise privacy terms. If they’re going to use AI regardless (and they will), make the sanctioned path easier than the personal one.

Make the paved road the fastest road. If using the official repo, the official CI pipeline, and the official review process is slower than doing it solo with a personal AI account, people will keep going solo. Fix the incentive.

Scan for what you don’t know about. Look for patterns: API keys in places they shouldn’t be, services calling external endpoints you didn’t approve, code repos that appeared outside your org’s GitHub or GitLab. The stuff you don’t know about is the stuff that hurts.

Talk about it openly. The problem isn’t that employees want to be productive. The problem is unmanaged productivity touching systems the organization is responsible for. Frame it that way. Not as a crackdown. As a boundary.

The real issue
#

Nobody is building shadow AI to cause problems. They’re building it because AI made them capable of solving problems nobody else was solving for them. That’s a sign of a motivated team. It’s also a sign that your official tooling and processes aren’t keeping up.

The fix isn’t to ban AI. It’s to make the managed path so good that nobody needs to go around it.

Dealing with shadow AI in your organization? I’d love to hear how you’re handling it. Find me on X or Telegram.

Governance · PiniShv

100 Days to the EU AI Act Deadline. Your Engineering Team Hasn't Started.

Who this actually applies to #

What the law actually requires (in engineering language) #

Article 50: Transparency #

Article 12: Record-keeping #

Article 14: Human oversight #

Article 5: Prohibited practices #

Why the legal team isn’t the bottleneck #

The 100-day plan #

Days 1 to 15 (now through May 9): Inventory and triage #

Days 16 to 50 (May 10 through June 13): Build the audit layer #

Days 51 to 80 (June 14 through July 13): Disclosure and oversight #

Days 81 to 100 (July 14 through August 2): Documentation and dry-runs #

The one thing that blows up the plan #

What to do this week #

AI Makes Code Cheap to Produce. Not Cheap to Own.

What the data says #

Where it breaks #

What to change #

The one-line version #

'I Only Built a Small Script for Myself.' That Might Be the Most Dangerous Sentence in Your Company.

The old version of this problem #

What shadow AI actually looks like #

Why this is different from old shadow IT #

What to actually do about it #

The real issue #

Who this actually applies to
#

What the law actually requires (in engineering language)
#

Article 50: Transparency
#

Article 12: Record-keeping
#

Article 14: Human oversight
#

Article 5: Prohibited practices
#

Why the legal team isn’t the bottleneck
#

The 100-day plan
#

Days 1 to 15 (now through May 9): Inventory and triage
#

Days 16 to 50 (May 10 through June 13): Build the audit layer
#

Days 51 to 80 (June 14 through July 13): Disclosure and oversight
#

Days 81 to 100 (July 14 through August 2): Documentation and dry-runs
#

The one thing that blows up the plan
#

What to do this week
#

What the data says
#

Where it breaks
#

What to change
#

The one-line version
#

The old version of this problem
#

What shadow AI actually looks like
#

Why this is different from old shadow IT
#

What to actually do about it
#

The real issue
#