Ingeniería
Cómo construimos sistemas de IA que deben funcionar de verdad
Estos principios guían nuestras decisiones de arquitectura, implementación y operación. No describen una tecnología concreta. Definen cómo reducimos complejidad, riesgo y dependencia mientras construimos sistemas que una organización puede comprender y controlar.
Diseñamos pensando en el día dos — no en la demo.
Diseñamos pensando en disponibilidad, mantenimiento, incidentes, costes, cambios y recuperación. Una demo prueba que algo puede funcionar. Un sistema de producción debe demostrar que puede seguir funcionando.
No te obligamos a mantener una infraestructura mayor de la que realmente necesitas.
Elegimos tecnologías según volumen, riesgo, latencia, equipo y capacidad operativa. Servicios gestionados, serverless, contenedores o Kubernetes cuando el problema lo justifica — no por moda ni por defecto.
Identidad, permisos y aislamiento forman parte de la arquitectura — no son añadidos posteriores.
Identidad, permisos, secretos, aislamiento y modelado de amenazas forman parte de la arquitectura inicial. Cada usuario, agente y herramienta recibe únicamente el acceso necesario para cumplir su función.
No todas las acciones requieren aprobación. Tampoco todas deberían ser autónomas.
No todas las acciones requieren aprobación. Tampoco todas deberían ser autónomas. Clasificamos las acciones según su impacto y aplicamos límites, aprobaciones, supervisión o bloqueo cuando el riesgo lo exige.
Entornos y despliegues deben poder reconstruirse de forma consistente.
Infraestructura, configuración y despliegues deben poder reconstruirse de forma consistente. Usamos infraestructura como código, control de versiones, automatización de entrega y entornos verificables para reducir errores manuales y configuraciones invisibles.
Si no podemos explicarlo, medirlo o investigarlo, no podemos operarlo con confianza.
Un sistema que no puede explicarse, medirse o investigarse no puede operarse con confianza. Incorporamos métricas, logs, trazas, auditoría, evaluaciones de IA y atribución de costes según la criticidad del sistema.
No fingimos que no existe vendor lock-in. Hacemos visibles y controlables las dependencias.
No prometemos cero vendor lock-in. Hacemos visibles y controlables las dependencias. Preferimos APIs documentadas, formatos portables, estándares abiertos y planes de salida razonables para evitar dependencias accidentales.
Primero estabilizamos el proceso. Después automatizamos lo repetible, verificable y seguro.
Primero comprendemos el proceso, sus excepciones y riesgos. Después automatizamos. Cada automatización debe ser verificable, observable, reversible y tener un responsable claro.
Las decisiones importantes y los procedimientos operativos quedan documentados y versionados.
Documentamos las decisiones que condicionan el sistema y la información necesaria para operarlo. Arquitecturas, ADRs, runbooks, ownership, permisos y procedimientos de recuperación permanecen versionados junto al sistema.
Cada componente adicional aumenta el coste de operación, seguridad y mantenimiento.
Cada componente adicional aumenta el coste de operación, seguridad y mantenimiento. Preferimos tecnologías conocidas, límites claros y diseños comprensibles antes que complejidad innecesaria.
Ayudamos a las empresas a usar IA con claridad, control y confianza — desde el primer caso de uso hasta una operación de IA gobernada.
Ingeniería · Principios
Cómo construimos sistemas de IA que deben funcionar de verdad
Reglas de decisión · Evidencia · Modelo operativo
Regla de decisión
Sin camino a producción sin runbooks, rollback, límites de coste y responsable de guardia definidos antes del go-live.
Evidencia
Regla de decisión
Preferir ejecución gestionada o serverless hasta que aislamiento, throughput, latencia, cumplimiento o escala organizacional justifiquen un runtime dedicado o plataforma Kubernetes.
Evidencia
Regla de decisión
Cada conector, herramienta y fuente de datos recibe scopes explícitos, aislamiento de credenciales y un modelado de amenazas antes del acceso a producción.
Evidencia
Regla de decisión
Clasificar acciones por radio de impacto; exigir aprobación, supervisión o bloqueos duros para operaciones de escritura, externas o irreversibles.
Evidencia
Regla de decisión
Sin cambio en producción sin IaC versionado, entrega automatizada y un camino verificable para reconstruir el entorno.
Evidencia
Regla de decisión
Cada camino de agente en producción incluye trazas, eventos de auditoría, hooks de evaluación y atribución de costes proporcional al impacto de negocio.
Evidencia
Regla de decisión
Documentar cada dependencia externa con portabilidad de datos, contratos de API y un plan consciente de salida o migración.
Evidencia
Regla de decisión
Automatizar solo cuando el proceso está comprendido, las excepciones documentadas y el rollback probado.
Evidencia
Regla de decisión
Cada decisión arquitectónica y procedimiento operativo que afecta a producción tiene un ADR o runbook versionado vinculado al sistema.
Evidencia
Regla de decisión
Rechazar componentes nuevos salvo que eliminen más complejidad de la que añaden — con evidencia.
Evidencia