Security is the last place you want AI making decisions
Security is the last place you want AI making decisions. I used it to harden a platform for public-sector compliance anyway — and the whole trick was making sure it never made a single security decision.
The job: ENS Medium, the 60-page framework you have to satisfy to sell software to Spanish public administrations. Dense, load-bearing, normally a dedicated specialist engagement. I had to cover it solo, in parallel with product work that couldn’t pause.
Delegating security judgment to a model is a hard no. So I didn’t. I framed the work so AI sat everywhere except the judgment seat.
What AI did:
- Framed the work to be done — read the 60 pages, mapped requirements to our architecture, flagged the gaps
- Produced the documents the administration required
- Sped up implementing the actual changes
Where the judgment stayed — two human gates:
- Me — testing the implementation, owning the final solution
- The customer — validating coverage and the high-level architecture
The model never validated its own security work. It couldn’t. That’s the point.
What shipped:
- MFA on admin access
- RBAC on sensitive endpoints
- Rate limiting and brute-force protection
- Webhooks hardened: idempotency, replay protection, HMAC signing
- PII encrypted at rest (name, surname, email) — behind a directory service so the data stayed queryable
- A security roadmap for monitoring, alerts, and audits
This is the same principle behind anything I ship with AI: keep the model out of the liability path by design. Here the stakes were maximal — security, public sector — and it still held. Introduced that way, AI didn’t add risk. It unlocked hardening that would otherwise have needed a specialist and a frozen roadmap.
When you bring AI into high-stakes work, how do you keep it out of the decisions it shouldn’t be making?