Cero fracasos de proyecto desde 2007: las reglas de ingeniería que lo sostienen
Fundé Software Tailor en 2006. Diecinueve años después, la empresa ha entregado a través de cuatro ciclos económicos distintos, ha servido a seis clientes Fortune Global 500 en farma, finanzas, gobierno, jurídico, defensa y energía, y acumula cero fracasos de proyecto desde 2007. Ese último número es el que con más frecuencia preguntan inversores y revisores de compras, y es el único que necesita explicación. Aquí van las cuatro reglas de ingeniería que sostienen el historial.
Regla 1: Un único modelo de entrega, sin mezcla servicios-vs-producto
Cada compromiso de Software Tailor se ejecuta sobre el mismo modelo de entrega: una fase piloto de alcance ajustado que entrega software funcional, seguida por una expansión que el cliente decide financiar (o no) a partir de lo que se entregó. No tenemos una práctica de «servicios» separada que entregue contra documentos de requisitos y otra práctica de «producto» separada que entregue contra hojas de ruta. Ambas chocarían; una siempre estaría subvencionando a la otra.
Un único modelo significa que cada ingeniero sabe cómo se ve «terminado» antes de empezar. Esa es la precondición para no fracasar.
Regla 2: Disciplina de cohorte de clientes — sólo clientes a los que podemos entregar
Nuestra cohorte de clientes está seleccionada, no es oportunista. Seis clientes Fortune Global 500 en 19 años no es un pipeline de ventas lento; es un listón de selección deliberado. Cada cliente que aceptamos tiene que pasar tres pruebas antes del kickoff: su problema es uno que ya hemos resuelto, su sponsor interno es la persona que usará el software (no una capa de intermediarios) y su entorno de hardware/datos nos permite entregar sin un rodeo de compras de seis meses.
Un cliente que falle cualquiera de esas pruebas se convierte en una derivación a otro proveedor, no en un proyecto. Esta es la regla que más a menudo nos cuesta ingresos. También es la que tiene cero excepciones en 19 años.
Regla 3: Disciplina de ingeniería alineada con un marco reconocido
Mucho antes de que la gestión del riesgo en IA tuviera su propio marco, las reglas de ingeniería que codifiqué para Software Tailor encajaban con el mismo patrón: gobernar el trabajo, mapear los riesgos, medir los resultados, gestionar los cambios. El NIST AI RMF 1.0 [1] formalizó ese patrón para la IA en 2023, y el perfil de Infraestructuras Críticas de abril de 2026 [1] lo extendió a los sectores regulados. Leyendo esos documentos, nuestra disciplina interna se proyecta con limpieza sobre las cuatro funciones.
Lo que eso nos da: cada proyecto es auditable de extremo a extremo contra un marco externo, no sólo contra nuestros propios hábitos. Cuando un equipo de compras pregunta cómo se decide el alcance de la fase piloto, la respuesta es la misma que daría NIST para la gestión de riesgos, y el equipo de cumplimiento del cliente ya ha interiorizado ese vocabulario.
Regla 4: Registrable, recuperable, recreable
La cuarta regla precede al vocabulario de rastro de auditoría que ahora usamos para AI Suite. Cada compromiso de Software Tailor se ejecuta en un estado en el que cualquier decisión, cualquier artefacto y cualquier versión del código pueden ser recreados a partir de entradas controladas por versiones. Eso no es inusual en ingeniería de software en general; lo inusual es que lo aplicamos al proyecto, no sólo a la base de código. Decisiones de sprint, cambios de alcance, aprobaciones del cliente: todo registrado, todo recuperable.
Esa disciplina explica por qué nuestro enfoque de registros de auditoría sin contenido para AI Suite se entregó como se entregó. El patrón de fila de auditoría es el mismo patrón que ya aplicábamos a los proyectos. El vocabulario está tomado de los marcos de cumplimiento; la práctica está tomada de cómo entregamos.
Qué se trasladó a AI Suite
La línea Local AI Suite + AI Admin Console —véase Por qué distribuimos IA como binarios instalables, no como SaaS en la nube— es la misma disciplina de ingeniería aplicada a una línea de productos en lugar de a un encargo a medida. Mismo modelo de entrega único (instaladores de escritorio que el cliente ejecuta en su propio entorno), misma disciplina de cohorte de clientes (sectores regulados con restricciones claras de residencia de datos), mismo mapeo de marcos (obligaciones del deployer del NIST AI RMF + EU AI Act), misma postura de auditoría registrable-recuperable-recreable.
Cero fracasos de proyecto desde 2007 no es un eslogan. Es el resultado de un pequeño número de reglas aplicadas sin excepción. Las mismas reglas rigen ahora cómo se construye AI Suite.
Referencias
- NIST. «AI Risk Management Framework (AI RMF 1.0).» nist.gov/itl/ai-risk-management-framework. Consultado el 2026-07-15.
Artículos relacionados
Ponga a prueba la misma disciplina en una carga de trabajo real.
La plataforma de IA on-premises se basa en las mismas reglas que produjeron el historial —registrable, recuperable, recreable, aplicadas sin excepción—. Despliéguela frente a una carga de trabajo real en su propio entorno y exíjale el mismo estándar.