La semana pasada vi el mismo tweet compartido en tres canales de Slack distintos. NullClaw: un binario de 678 KB, ~1 MB de RAM, arranque en menos de 2 ms, soporte para más de 22 proveedores de IA, licencia MIT, escrito en ~45.000 líneas de Zig. Impresionante. Cada vez que alguien lo compartía, la pregunta era la misma: “¿podemos usar esto?”

Esa pregunta parece simple. No lo es. Tiene supuestos escondidos que nadie dice en voz alta: que porque es open-source es gratis, que porque tiene tests está probado, que porque funciona en un demo va a funcionar en producción. Y ahí es donde empiezan los problemas.

678 KB, 22 proveedores, cero garantías

No voy a decir que NullClaw no es impresionante — lo es. Un binario de 678 KB que maneja 22+ proveedores de IA con tiempos de arranque inferiores a 2 ms es una pieza de ingeniería notable. Pero hay una diferencia enorme entre “esto es impresionante” y “esto está listo para producción empresarial”.

En nuestra experiencia en IQ Source, ~80% de las herramientas open-source que los clientes nos traen para evaluar no sobreviven un análisis serio. No porque sean malas herramientas. Porque no fueron diseñadas para lo que el cliente quiere hacer con ellas.

Lo que no aparece en el README

Cada vez que evaluamos una herramienta open-source, hacemos el mismo ejercicio: separar lo que ves de lo que obtienes.

Lo que ves	Lo que obtienes
Licencia MIT, gratis	Sin SLA, el mantenedor puede desaparecer mañana
2.738 tests	Escritos por la misma persona, sin auditoría independiente
22+ proveedores	22+ API keys, 22+ superficies de ataque
~45.000 líneas de Zig	Pool de talento diminuto — ¿quién mantiene esto?
”Sandboxing multi-capa”	Afirmaciones que no puedes verificar sin revisión de seguridad
Comunidad activa	Dependencia de la motivación de fin de semana de un desconocido

Tres riesgos que vemos repetidamente:

Ataques a la cadena de suministro

En 2024, un desarrollador insertó un backdoor en XZ Utils — una librería de compresión que nadie mira pero que está en casi todo servidor Linux (CVE-2024-3094). Pasó dos años ganándose la confianza del proyecto antes de actuar. Si puede pasar con infraestructura crítica que millones de servidores usan, puede pasar con cualquier herramienta de IA que tu equipo descarga de GitHub un martes por la tarde.

Riesgo de abandono

Según el estudio de Tidelift sobre mantenedores open-source, el 60% de los mantenedores no remunerados trabajan solos en sus proyectos. Un cambio de trabajo, un burnout, una decisión de vida — y tu dependencia crítica se queda sin soporte. No hay SLA al que llamar. No hay contrato que te proteja.

Costos de infraestructura ocultos

Un binario de 678 KB suena a cero costo operacional. Pero 22 proveedores significan 22 conjuntos de credenciales que rotar, 22 políticas de uso que monitorear, 22 puntos de falla que diagnosticar cuando algo sale mal a las 3 de la mañana. El binario es ligero. La operación no.

Si estás evaluando proveedores de IA, escribimos sobre los criterios que usamos en selección de proveedores de IA para B2B.

El problema con el código que nadie entiende

Hay otro fenómeno que vemos cada vez más: el vibe coding. Si no has oído el término, es cuando alguien usa un asistente de IA para generar código — aceptando sugerencia tras sugerencia sin realmente entender qué hace cada línea ni por qué.

Un prospecto nos mostró hace poco una herramienta que su equipo construyó en dos días con un asistente de IA. Funcionaba. Querían pasarla a producción. Les hicimos tres preguntas y la conversación cambió por completo:

1. ¿Qué pasa cuando esta función recibe datos que no espera?
2. ¿Pueden explicarme la lógica de autenticación línea por línea?
3. ¿Dónde está la validación de entrada antes de enviar datos a la API externa?

Silencio. No porque no supieran de tecnología. Porque nunca habían leído el código que estaban a punto de desplegar.

No entiendes lo que estás desplegando

Código que no puedes explicar es código que no puedes debuggear a las 2 de la mañana. No puedes extender cuando los requisitos cambian. No puedes justificar ante un auditor. Y si el modelo de IA que lo generó cambia de versión o deja de estar disponible, no puedes reproducirlo.

Las vulnerabilidades que el modelo no ve

El código generado por IA introduce patrones que los escáneres de seguridad estándar no detectan. Validación de entrada incompleta, condiciones de carrera sutiles, secretos hardcodeados que “funcionan en dev”. OWASP publicó un Top 10 específico para aplicaciones LLM que identifica estos vectores — y la mayoría de los equipos que hacen vibe coding no lo conocen.

Para más detalle sobre cómo evaluamos la seguridad del código generado por IA, tenemos un artículo dedicado sobre seguridad de código IA en contexto empresarial.

Deuda técnica acelerada

Código que funciona pero no fue diseñado. Velocidad en la semana uno, costo multiplicador para el mes seis. Hemos visto equipos que construyeron un MVP en días con IA y después tardaron meses en reescribirlo cuando necesitaron agregar una integración que el diseño original no contemplaba. El código generado tiende a resolver el problema inmediato sin considerar cómo va a evolucionar.

Compliance no acepta “lo hizo la IA”

SOC 2, ISO 27001, HIPAA — todos exigen cadenas de responsabilidad claras. ¿Quién escribió este código? ¿Quién lo revisó? ¿Qué proceso garantiza que cumple con los controles de seguridad? “Lo generó un modelo de lenguaje y parecía funcionar” no es una respuesta que ningún auditor acepte.

Checklist: 8 preguntas antes de adoptar

En IQ Source usamos estas preguntas cada vez que un cliente nos trae una herramienta o código generado para evaluar. Si no puedes responder a más de dos con confianza, la herramienta no está lista para producción.

1. ¿Quién es dueño de esta dependencia? — Si el factor bus es 1, tu riesgo es alto. Busca quién mantiene el proyecto, cuántos contribuidores activos tiene, y si hay una organización o empresa detrás.

2. ¿Qué pasa cuando falla a las 3 AM? — ¿Hay canal de soporte? ¿Tiempo de respuesta documentado? ¿O dependes de que alguien vea tu issue en GitHub?

3. ¿El código ha sido auditado de forma independiente? — Revisa si existe un archivo SECURITY.md, un programa de bug bounty, o reportes de auditoría publicados. Tests escritos por el mismo desarrollador no cuentan como auditoría.

4. ¿Tu equipo puede leer, debuggear y modificar este código? — Si está en un lenguaje que nadie en tu equipo domina (Zig, Rust, etc.), estás creando un lock-in de talento. Cuando algo falle, necesitas gente que pueda entrar al código.

5. ¿Cuál es la licencia — de verdad? — MIT hoy no garantiza MIT mañana. HashiCorp cambió a Business Source License. Redis pasó a SSPL. Lee la licencia completa y evalúa qué pasa si cambia.

6. ¿A dónde van tus datos y prompts? — Con 22 proveedores tienes 22 políticas de privacidad distintas. ¿Cuáles retienen datos? ¿Cuáles entrenan con tus prompts? ¿Quién es responsable de un breach?

7. ¿Cuál es el plan de salida? — Si mañana necesitas migrar, ¿cuánto cuesta? ¿Hay formato estándar de export? ¿O estás construyendo sobre una abstracción que solo existe en esta herramienta?

8. ¿Quién revisa el código generado por IA antes de desplegarlo? — No si lo revisan, sino quién, cómo, y contra qué criterios. “Lo probé y funciona” no es revisión de código.

Lo que hacemos en IQ Source

No voy a convertir esto en un pitch de ventas. Pero sí quiero ser transparente sobre cómo abordamos esto con clientes, porque creo que el proceso importa.

Cuando un cliente nos trae una herramienta open-source o código generado por IA, lo primero que hacemos es correr las 8 preguntas del checklist. Es un filtro duro. Aproximadamente 4 de cada 5 herramientas que llegan no pasan para uso en producción — no porque sean malas, sino porque el gap entre “funciona en mi máquina” y “funciona en producción empresarial con auditoría, soporte y continuidad” es enorme.

Para las que sí pasan, diseñamos la arquitectura de integración: sandboxing real, monitoreo, fallbacks, gobernanza de datos. No es solo “instalar y conectar”.

Y para el código generado por IA, hacemos revisiones dirigidas a los patrones que los modelos suelen equivocar: validación de entrada ausente, condiciones de carrera, supuestos hardcodeados que funcionan en dev pero explotan en producción.

Las herramientas de IA open-source y el vibe coding son la receta. Lo que nosotros aportamos es el criterio del chef.

---

Si tu equipo está evaluando herramientas de IA open-source o llevando código generado por IA a producción, podemos correr un assessment de riesgo sobre las herramientas específicas de tu stack. Agenda el assessment — 30 minutos que pueden ahorrarte meses.