Audité mi propia empresa con AI (y el número que salió no me gustó)

Hay una conversación que se repite en casi cualquier equipo de ingeniería. Alguien dice que un sistema "se siente frágil". Otra persona responde que "ha estado bastante estable". Un tercero propone atacar "el módulo de siempre". Y la reunión termina con una decisión tomada por intuición o, peor, por quien argumentó con más seguridad.

He estado en las tres sillas. Y en algún punto me hice una pregunta incómoda: si presumimos de ser una disciplina rigurosa, ¿por qué las conversaciones más importantes sobre la salud de nuestros sistemas se resuelven con adjetivos?

De ahí nació un método de auditoría asistida por AI con una regla central: si un hallazgo no puede citarse a evidencia concreta —archivo, línea, commit—, no es un hallazgo; es una sospecha, y las sospechas no entran al reporte. La AI no está ahí para opinar: está para ampliar la superficie de análisis, revisar más código, más dependencias y más escenarios de los que una persona alcanza en el mismo tiempo. El criterio de qué importa y qué se corrige primero sigue siendo humano.

Pero un método así tiene un problema de legitimidad evidente: es muy cómodo auditar el trabajo ajeno. Así que antes de pedirle a cualquier equipo que aceptara ser medido, decidí apuntar el método hacia el lugar donde más me dolería: mi propia empresa.

Mi propia casa

Binpet es la empresa de software veterinario que fundé y opero. No es un proyecto de fin de semana: es una plataforma clínica para veterinarios, una aplicación para tutores de mascotas, un panel de administración B2B y una capa de comercio, construida sobre tres stacks distintos e integrada con pasarelas de pago, mensajería, correo transaccional y varios proveedores de AI.

Y aquí viene el primer dato que la auditoría puso sobre la mesa, uno que yo "sabía" pero nunca había visto escrito con esa crudeza: Binpet no es un repositorio. Es un workspace de ocho repositorios independientes más cinco carpetas de trabajo no versionadas. Trece proyectos en total. Mantenidos por una sola persona.

Eso no es un monorepo. Es un holding de productos operado por AI, donde el humano funciona como director de orquesta y cada repositorio avanza en sesiones de trabajo con AI que se documentan y se retoman en frío.

Suena bien contado así. La auditoría existe precisamente para verificar si suena igual de bien medido.

Los números tal cual

Primero, la actividad real, sacada del historial de Git y no de mi memoria: el backend concentra 470 commits y sigue activo al día de hoy; la aplicación web clínica lleva 248; la app móvil para veterinarios, 96. Hasta ahí, el retrato de una operación viva.

Pero el mismo inventario mostró la otra cara: un gateway de AI con dos commits, dormido desde abril. Un panel white-label para un cliente de referencia, congelado. Una app pausada desde junio. El historial de Git no tiene diplomacia: registra con la misma frialdad lo que avanzas y lo que abandonas.

Después evalué el modelo operativo completo con una rúbrica de nueve dimensiones, cada una de 0 a 10. Aclaración importante, porque el método me obliga a hacerla: los conteos de proyectos, commits y superficies vienen directo del repositorio; los puntajes son mi evaluación contra criterios explícitos. Los pesos de una rúbrica son decisiones de criterio, no verdades reveladas. Lo que vuelve útil el ejercicio no es que el número sea "objetivo" en abstracto: es que los criterios están escritos, la evidencia es citable y la medición se puede repetir dentro de seis meses para ver el delta.

Las dimensiones fuertes salieron fuertes: la AI dentro del producto quedó en 8.5 —ocho superficies distintas de AI, cada una con control de costo por diseño, incluyendo triage con un modelo self-hosted cuyo costo marginal es cero—. La AI como equipo operativo, 9.0. La cobertura de dominio, 9.0. La reanudabilidad del contexto entre sesiones, 9.5.

Y luego las que dolieron. Foco: 3.0. Calidad y verificación: 3.5. Continuidad y bus factor: 4.0.

El índice compuesto quedó en ≈ 6.6 sobre 10. El veredicto en una línea: ejecución técnica excepcional, lastrada por dispersión y por una red de verificación más débil que la velocidad a la que se produce.

Hay un patrón en esos números que no voy a fingir que no veo: las dimensiones donde salgo bien son las que yo mismo diseñé para mi forma de trabajar —AI en el producto, AI como equipo, reanudabilidad—, y las que duelen son las clásicas que la industria lleva décadas sabiendo medir: foco, verificación, continuidad. Podría leerse como autoindulgencia calibrada. Yo lo leo al revés: lo nuevo lo construí con estándar alto porque no tenía excusa ni inercia, y lo básico lo descuidé porque la velocidad me lo permitía. Ninguna de las dos lecturas se resuelve discutiendo; se resuelve midiendo otra vez.

Confieso que mi percepción, antes de medir, rondaba el 8. Esa brecha de casi punto y medio entre lo que yo sentía y lo que la evidencia sostenía es, exactamente, la razón por la que el método existe.

¿Y el costo? No llevo bitácora de horas, pero sí de facturas. Antes pagaba equipos externos de desarrollo y QA —con tarifas bajas, además— y la cuenta rondaba los $10,000 USD al mes para avanzar en plazos de meses. Hoy ese mismo tipo de avance —incluida esta auditoría— se mide en días o semanas, y toda mi operación de AI no rebasa los $250 USD al mes. Cuarenta veces menos costo, con una velocidad que se mide en otra unidad de tiempo. Lo pongo con números porque es parte del argumento: el mapa de salud completo de una empresa cuesta menos que una sola decisión de foco mal tomada.

Lo que el número me obligó a ver

Tres cosas que yo no habría formulado sin el ejercicio.

La primera: la AI hace barato abrir el proyecto trece; no hace barato mantenerlo. Cada proyecto dormido de mi inventario nació en una tarde productiva con AI. Ese es el riesgo AI-native del que casi nadie habla: la herramienta elimina la fricción de empezar, y la fricción de empezar era, en el fondo, un mecanismo natural de foco. Cuando desaparece, la disciplina tiene que ser explícita porque ya no viene gratis.

La segunda: mi cuello de botella ya no es escribir código, es verificarlo. Un backend con esa cadencia de commits y una cobertura de pruebas muy por debajo de donde debería estar significa una cosa: la AI produce más rápido de lo que cualquiera —humano o máquina— está validando. "Compila" no es "funciona", y un sistema en producción no se puede dar el lujo de confundirlos. Esta es la dimensión donde más he invertido desde la auditoría.

La tercera, y la más incómoda: el activo más frágil de la empresa no es ningún repositorio. Es la continuidad del contexto. Todo el modelo funciona porque el estado del trabajo vive fuera de mi cabeza: bitácoras de progreso como fuente de verdad, prompts maestros para retomar cualquier sesión en un chat nuevo, memoria persistente entre sesiones. Cada sesión de AI es, en la práctica, un empleado nuevo que llega sin contexto; la bitácora es su onboarding. Si un día cierro una sesión sin actualizar la bitácora, el sistema pierde memoria y el bus factor colapsa a uno de verdad. La bitácora es la empresa.

Lo que decidí corregir — y lo que decidí no corregir

Aquí es donde una auditoría se distingue de un reporte bonito: en que produce decisiones.

Lo primero fue quirúrgico: congelar formalmente lo dormido. No borrarlo, no "retomarlo algún día": marcarlo explícitamente como congelado para que ninguna sesión futura —mía o de la AI— lo despierte por accidente. La conclusión estratégica del ejercicio cabe en una frase que me sigue picando: apagar el 60% y medir el 40%.

Lo segundo fue atacar la verificación: un pipeline mínimo por repositorio activo antes de cualquier merge. Si la AI escribe, algo tiene que verificar. No es sofisticado; es higiene que la velocidad me había permitido postergar.

Y lo tercero, igual de importante: hubo hallazgos que decidí no corregir todavía. Dimensiones con puntaje mediocre cuyo arreglo hoy costaría más foco del que devuelve. Esa es la parte del método que más defiendo: una auditoría no es una lista de culpas a saldar completa; es un instrumento para decidir dónde rinde el esfuerzo. Corregirlo todo de inmediato sería, irónicamente, repetir el error de la dispersión.

Por completar el cuadro: también corrí una auditoría de seguridad sobre el producto, con seis auditores de AI trabajando en paralelo sobre el mismo código y una remediación gobernada por fases. De sus hallazgos no voy a dar detalles —es un producto en producción y la discreción es parte de la responsabilidad—, pero sí comparto la lección meta que me dejó: detectar es la parte barata. El error de verdad se cuela al planear la remediación, cuando uno asume que la lista de tareas cubre la lista de hallazgos y nadie verifica ese cruce. Desde entonces, el plan de remediación también se audita.

Las dos IA de esta historia: en el producto y como equipo

Vale la pena separar algo que suele mezclarse. En Binpet hay AI en dos lugares distintos, y confundirlos es no entender el modelo.

Está la AI dentro del producto: la que ven los usuarios. Un agente financiero que le explica sus números a la clínica, chat clínico con búsqueda sobre expedientes, triage de síntomas, importación inteligente de inventarios. Cada superficie con presupuesto, con niveles de modelo según la tarea —modelos baratos para lo mecánico, self-hosted para lo de alto volumen— porque en un SaaS el costo de AI sin gobierno se come el margen en silencio.

Y está la AI como equipo: la que opera la empresa. Ingeniería por sesiones documentadas, auditoría de seguridad en paralelo, análisis financiero, decisiones de infraestructura, generación de matrices de prueba, estrategia. El humano decide y da luz verde; la AI ejecuta en ramas aisladas; todo estado vive en Markdown para poder retomarse en frío.

La primera es el producto. La segunda es la ventaja operativa difícil de copiar. Y la auditoría midió las dos con la misma vara.

Operar una empresa con IA: la tesis que me llevo

Si tuviera que comprimir todo el ejercicio en una idea, sería esta: gestionar una empresa multi-vertical con AI como equipo es posible cuando el estado vive fuera del humano —en artefactos reanudables— y cuando aceptas que el cuello de botella dejó de ser escribir código y pasó a ser verificarlo.

La percepción me decía que Binpet era un 8. La evidencia dijo 6.6, y me explicó exactamente por qué y exactamente dónde. Con eso no gané un número para presumir; gané un mapa de en qué orden invertir mi recurso más escaso, que es mi propio foco.

Por eso este artículo no termina aquí. La rúbrica ya está escrita y la foto tomada: en seis meses vuelvo a medir con exactamente los mismos criterios y publico el delta, salga el número que salga. Un índice aislado es una opinión bien vestida; una serie de mediciones con la misma vara es evidencia. Si el método vale lo que digo que vale, tiene que sobrevivir a su segunda medición.

Esa es la clase de ingeniería que quiero impulsar: la que puede sostener sus afirmaciones con evidencia, incluso —especialmente— cuando el sistema auditado es el propio y el número que sale no es el que uno quería ver. "Se siente frágil", ya lo comprobé en carne propia, tampoco es diagnóstico cuando lo dices de tu propia empresa.