IA Sin Ingenieros: Error

Usar IA sin revisión humana no ahorra costos — abre puertas que cualquier atacante puede cruzar.

[DATO REAL]: Un estudio de Stanford (2023) encontró que los desarrolladores que usaron asistentes de IA produjeron código con un 76% más de vulnerabilidades de seguridad que quienes escribieron el código a mano — y se sentían más seguros sobre la calidad de su trabajo. Fuente: arxiv.org/abs/2211.03622

En este artículo vas a:

• Entender exactamente qué puede y qué no puede hacer la IA en desarrollo de software
• Ver las 4 preguntas que toda empresa debería hacerle a su proveedor de software antes de contratar
• Saber cómo usar IA como multiplicador de fuerza sin sacrificar seguridad
• Evaluar si tu operación actual tiene el nivel de supervisión humana que necesita

01 EL PROBLEMA REAL

El código generado por IA compila. Pasa los tests básicos. Funciona. Ese es exactamente el problema.

“Funciona” y “está listo para producción” son dos cosas completamente diferentes. Y la brecha entre esas dos cosas — vulnerabilidades sin parchear, secretos hardcodeados, falta de rate limiting, cifrado incompleto — es por donde entran los atacantes.

Un atacante no necesita que todo tu código sea vulnerable. Necesita una sola puerta abierta. El código generado automáticamente está lleno de puertas que nadie revisó.

PIÉNSALO ASÍ

Es como decir que tu carro enciende. Bien. Pero, ¿tiene frenos? ¿Tiene airbags? ¿Aguanta un choque a 120 km/h? El código generado por IA enciende. Lo que no tiene son frenos.

Sin revisión humana	El costo	Con ingenieros reales
Código que “funciona” en dev	Breach, pérdida de datos, multas SIC	Código que aguanta producción real

02 POR QUÉ PASA

Los LLMs predicen el siguiente token. No modelan amenazas, no conocen tu infraestructura, no saben qué cambia tu proveedor de pagos sin aviso.

El código que genera un modelo de lenguaje refleja los patrones estadísticos de su entrenamiento — incluyendo los malos. Si la mayoría de los ejemplos de StackOverflow que vio no implementaban rate limiting, el modelo tampoco lo va a implementar. Si los ejemplos de autenticación en su dataset tenían secrets hardcodeados, el modelo va a reproducir ese patrón.

El resultado es código que se ve limpio, pasa linters y hasta tiene tests unitarios en verde — pero con huecos de seguridad que ninguna herramienta automática detecta sin contexto de negocio.

Y el fenómeno es peor de lo que parece: los desarrolladores que usan IA reportan sentirse más confiados en la calidad de su código. Es el equivalente digital de cerrar la puerta con llave y dejar todas las ventanas abiertas.

03 LA SOLUCIÓN

La IA es la herramienta más poderosa que ha llegado al desarrollo de software en décadas. El problema no es usarla — el problema es usarla sin supervisión humana.

Lo que la IA sí hace bien:

• Acelerar prototipado — lo que tomaba una semana ahora toma horas
• Automatizar testing — detectar patrones que un humano tardaría días en encontrar
• Generar documentación desde el código, no desde la imaginación
• Identificar deuda técnica y sugerir mejoras de rendimiento

Lo que la IA no puede hacer:

Diseñar arquitectura que no se caiga. La diferencia entre “funciona en mi laptop” y “funciona con 10,000 usuarios simultáneos sin perder datos” se llama arquitectura. Y la arquitectura no se aprende con prompts — se aprende con años de ver cosas explotar en producción. Bases de datos bajo carga, colas de mensajes saturadas, cachés que se invalidan, firewalls con reglas específicas: eso lo diseña un ingeniero senior, no un modelo.

Auditar su propio output. Preguntale al LLM si valida inputs contra inyección SQL — te va a decir que sí. Revisá el código — probablemente no de forma consistente. La IA no tiene criterio para evaluar lo que genera. Un ingeniero sí.

Responder a las 3AM. Cuando tu sistema de facturación se muere y estás perdiendo $50,000 por hora, no le mandás un prompt a ChatGPT. Llamás a un ingeniero que conoce tu infraestructura, tu base de datos, tus integraciones y los secretos sucios de tu código legacy. La IA no tiene oncall. La IA no tiene contexto de negocio.

Proteger la soberanía de tus datos. Cada vez que tu código pasa por una API de IA en la nube, tus datos pasan por servidores que no controlás. ¿Dónde quedan? ¿Quién tiene acceso? ¿Cumple con la Ley 1581? Esas preguntas se responden con infraestructura propia, cifrado end-to-end y un equipo que implementa auditoría y trazabilidad real.

El modelo correcto: la IA como multiplicador de fuerza, los ingenieros como responsables. Cada línea que genera la IA pasa por revisión humana. Cada deployment tiene un ingeniero con nombre y apellido. Cada decisión de arquitectura la toma un profesional con contexto de negocio.

04 CÓMO IMPLEMENTARLO

1. Auditá el proceso actual. ¿Alguien revisa el código que genera la IA antes de que llegue a producción? ¿Hay un proceso formal o es “si compila, sube”?
2. Definí quién es responsable de seguridad. No el equipo en general — una persona específica con nombre, apellido y autoridad para frenar un deployment.
3. Implementá code review con enfoque de seguridad. Cada PR debería tener al menos una revisión de alguien que entiende los vectores de ataque: inyección SQL, XSS, secrets hardcodeados, acceso sin autenticación.
4. Integrá SAST y análisis de dependencias en el CI/CD. Automatizado en cada push. Si introducís una vulnerabilidad conocida, el pipeline para antes de que llegue a staging.
5. Hacé threat modeling antes de codear. ¿Qué datos maneja el sistema? ¿Quién podría querer acceder? ¿Qué pasa si falla cada componente?
6. Documentá y practicá el plan de respuesta. Un documento de 5–10 páginas: si pasa X, hacemos Y. Practicadlo al menos una vez al año.

05 ¿ES PARA TI?

Sí, si tu empresa:

• ✅ Está generando o comprando software que usa IA en alguna parte del proceso
• ✅ Maneja datos de clientes, pagos o información sensible en sus sistemas
• ✅ No tiene claro hoy quién revisa la seguridad del código que se despliega

No, si:

• ❌ Tenés un equipo de ingeniería interno maduro con procesos formales de revisión de seguridad ya funcionando
• ❌ Solo usás software de terceros empaquetado (SaaS) sin desarrollo propio

Preguntas frecuentes

¿El código generado por IA es más barato si no lo revisa nadie? A corto plazo parece que sí. A largo plazo, un breach cuesta entre 3x y 10x lo que habrías gastado en revisión. Sin contar las multas de la SIC (hasta 2,600 millones de pesos en 2026) si el breach expone datos personales.

¿Cómo sé si mi proveedor actual tiene revisión humana real? Hacele estas 4 preguntas: ¿Quién revisa la seguridad del código generado por IA? ¿Quién diseñó la infraestructura de despliegue? ¿Quién responde si algo falla a las 3AM un domingo? ¿Sabés exactamente dónde están tus datos y quién tiene acceso? Si cualquier respuesta es “no sé” o silencio incómodo — tenés un problema de seguridad, no de presupuesto.

¿DCM usa IA en el desarrollo? Sí, todos los días. Para prototipado, testing, documentación y refactorización. Pero cada línea que genera la IA pasa por revisión humana. Cada deployment tiene un ingeniero responsable. La IA es el multiplicador de fuerza; el cerebro detrás sigue siendo humano.

Acción inmediata: Buscá en tu repositorio actual estas cadenas: password =, secret =, api_key =. Si aparecen valores hardcodeados en el código (no en variables de entorno), ya encontraste tu primer hueco de seguridad — y tardaste menos de 5 minutos.

¿Quieres ayuda? → Hablá con DCM — llevamos 12+ años construyendo software que no se cae, no se hackea y no depende de prompts para funcionar.

Let me paint you a picture. Your dev team — or maybe a freelancer you found online — just shipped a new feature. Built in record time, mostly with AI-generated code. Looks great, passes basic tests, the demo went smooth. Everyone’s happy.

Except nobody reviewed the authentication logic. Nobody checked if the API endpoints sanitize inputs. Nobody asked where user credentials are stored or how session tokens are handled.

Congratulations. You just rolled out the red carpet for every attacker on the internet.

The number that should keep you up at night

A Stanford University study (2023) found that developers using AI coding assistants produced code with 76% more security vulnerabilities than those writing code manually. Read that again. Not 7%. Not 17%. Seventy-six percent.

And here’s the kicker — the developers using AI tools were more confident their code was secure. They trusted the output because it looked clean, compiled fine, and the AI sounded authoritative. It’s like slapping a smart lock on your front door while leaving every window wide open.

This isn’t a theoretical risk. This is happening right now, in production, at companies that think they’re “innovating with AI.”

Anyone can generate code. That’s the easy part.

I’ll be blunt: the barrier to writing code just dropped to zero. A marketing intern with ChatGPT can generate a REST API in 20 minutes. That’s not an insult — it’s genuinely impressive technology.

But here’s what that intern can’t do:

Design architecture that survives reality. AI generates functions. A senior engineer designs how those functions interact with databases, message queues, caches, load balancers, and firewalls under load. The gap between “works on my laptop” and “works with 10,000 concurrent users at 2x expected traffic” is architecture. That knowledge comes from years of building things that broke — and fixing them at 3AM while the CEO is on the phone asking why customers can’t log in.

Audit security at every layer. Does the generated code validate inputs against SQL injection? Are secrets hardcoded or pulled from a vault? Is there rate limiting on the login endpoint? Is data encrypted in transit and at rest? Is there an audit trail? A security-minded engineer checks each of these. A prompt doesn’t even know to ask. We documented the top 5 ways AI code gets you hacked — from SQL injection to slopsquatting — with real examples from production codebases.

Respond when everything is on fire. At 3:00 AM, when your billing system goes down and you’re hemorrhaging $50,000 per hour, you don’t open a chat window. You call an engineer who knows your infrastructure, your codebase, your deployment pipeline, and your business logic. Someone who can SSH into a production server, read the logs, find the root cause, and fix it — while calmly communicating status to stakeholders. AI doesn’t carry a pager. AI doesn’t have an on-call rotation.

Protect your data from everyone — including your tools. Every time you paste proprietary code into a cloud AI, where does it go? Who trains on it? Does your AI-generated codebase comply with Colombian data protection law (Ley 1581)? With GDPR if you have European users? A real engineering team deploys on infrastructure you control, with encryption, logging, and complete traceability. No data leaves your perimeter unless you explicitly decide it should.

How we actually use AI (because we’re not Luddites)

At DCM System, we’ve been building production software for over 12 years. We use AI every single day. It’s an extraordinary accelerator:

• Prototyping — first drafts of code 10x faster, then we rewrite the parts that matter
• Test generation — catching edge cases a human would spend hours mapping out
• Documentation — generating technical docs from code, then editing for accuracy
• Refactoring — spotting patterns and suggesting performance improvements across large codebases

But — and this is the part most “AI-first” agencies skip — every line AI generates goes through human review. Every deployment has a named engineer responsible. Every architecture decision is made by someone who understands the business context, the threat model, and the operational reality.

AI is our most powerful tool. It’s not our replacement. The same way a nail gun is incredibly useful, but you still need a carpenter who knows which wall is load-bearing. If you want to see how we configure AI tools for maximum leverage with proper guardrails, read our complete Claude Code guide with skills, hooks, and security.

What you’re actually paying for

When you work with an engineering team that has 12+ years of battle scars, you’re not paying for lines of code. Code is cheap now. You’re paying for:

• Architecture that doesn’t collapse — learned across 150+ production projects
• Security methodology — refined working with enterprise clients who can’t afford breaches
• Hardened infrastructure — Docker, Kubernetes, CI/CD pipelines with security gates at every step
• A human who knows your system end to end — not a rotating cast of anonymous contractors
• Data sovereignty — your data stays under your control, period

Four questions before your next project

Before you hand your next project to whoever promises the fastest delivery with the lowest price, ask them:

1. Who reviews the security of the AI-generated code? If the answer is “the AI checks itself” — run.
2. Who designed the infrastructure architecture? If they can’t explain their deployment topology in detail — that’s a red flag.
3. Who responds when production breaks at 3AM? If there’s no on-call process — you’re gambling.
4. Where is your data, and who has access? If they can’t answer this in one sentence — they don’t know either.

If any of these answers make you uncomfortable, you don’t have an engineering team. You have a liability. Let’s fix that.

At DCM System, we’ve been building secure, production-grade software since before “AI-generated code” was a phrase anyone used. If you want to talk about what real engineering looks like for your project — let’s have that conversation.