Cómo trabajamos
Del diagnóstico a una adopción medible
Las mismas cinco fases que en la portada y, debajo, la disciplina de ingeniería que hace comprobable cada una.
- 1Alinear y diagnosticar
La dirección acuerda el valor en juego; procesos, la IA ya en uso y la madurez se mapean con evidencia.
Medido por: un suelo de valor firmado y una línea base de madurez
El motor más trabajo en persona
Etapas de la columna: Alinear · Descubrir · Diagnosticar
- 2Rediseñar el trabajo
El flujo se reconstruye alrededor de la IA: quién decide, dónde revisa una persona, cómo se dimensiona el equipo.
Medido por: derechos de decisión firmados por sus responsables
El motor más trabajo en persona
Etapas de la columna: Priorizar · Diseñar
- 3Probarlo en un piloto gobernado
Un flujo de alto valor, con clasificación según la Ley de IA de la UE, evidencias y registro de auditoría desde el inicio.
Medido por: tiempo de ciclo y valor frente al suelo
El motor más trabajo en persona
Etapas de la columna: Gobernar · Pilotar · Desplegar · Probar
- 4Sumar a las personas
Aprendizaje por rol, una red de campeones y bibliotecas de prompts y agentes por equipo, para que la nueva forma de trabajar sea la que se usa.
Medido por: adopción por flujo
En persona con sus equipos
Aún sin etapa en el motor: se entrega en persona con sus equipos.
- 5Escalar lo que funciona
Los éxitos se convierten en módulos estándar con responsables, un ritmo operativo y un registro de valor.
Medido por: valor realizado, no licencias
El motor más trabajo en persona
Etapas de la columna: Escalar · Aprender
Llevamos la IA de los pilotos al trabajo diario de organizaciones reguladas. Eso significa rediseñar el flujo de trabajo al que pertenece la IA, acordar quién decide y quién revisa, y sumar a las personas que hacen el trabajo. También significa gobernarla para que pueda escalar, con cada paso terminando en un registro que firma su responsable.
Riaan ha construido productos de IA él mismo, entre ellos verificación de voz e identidad, así que conocemos el lado técnico desde dentro. Pero lo que decide si la IA se adopta rara vez es el modelo; es el entorno operativo que lo rodea. Ahí es donde trabajamos.
Prueba de honestidad VERIFIED el 2026-10-15 — 5 comprobaciones (typecheck, lint, tests, paridad i18n, Archify doctor).
No que conozcamos la IA, sino que sabemos cómo hacerla adoptable dentro de organizaciones reales.
«Muchos proyectos de IA fracasan porque el modelo funciona pero el entorno operativo no. Nuestro trabajo se centra en el entorno operativo: identidad, datos, flujo de trabajo, permisos, revisión, integración, despliegue y aceptación medible.»
El motor detrás de este sitio es esa forma de trabajar, hecha visible: cada sesión termina en hechos y firmas, cada cifra tiene una fuente y lo desconocido se muestra como desconocido. Es cómo trabajamos, no una licencia que vendemos.
Lo que entrega un proyecto: IA que su organización usa, asume y puede medir, no otro piloto.
Escalar de forma predecible — bien dimensionado, bien preciado, bien entregado.
La mayoría de organizaciones usa IA en algún sitio; pocas la han escalado. Lo que falta rara vez es el modelo — es el modelo operativo: cómo se dimensiona, se precia y se firma el trabajo. El coste baja como resultado de hacerlo bien, no como objetivo.
- 1Bien dimensionado
Cada tipo de trabajo se dimensiona por lo que lo hace crecer: quienes producen por el trabajo, quienes piensan por las iniciativas que sostienen a la vez, quienes lideran en personas enteras. Sin sobre ni infradotación — y lo dice cuando la respuesta es 'añadir'.
El mismo trabajo contado de dos formas → - 2Bien preciado
Precio por resultado, no por puesto, con el margen fijado antes de firmar y cada supuesto nombrado. Un precio que se sostiene al crecer el volumen, porque cada parte del equipo tiene su propio impulsor.
Ver las ofertas → - 3Bien entregado
Nada avanza sin la puerta y la firma que le corresponde — lo que puede hacer un agente, lo que decide una regla, lo que firma una persona. La promesa hecha en la sala se mantiene después.
Quién firma qué →
Debajo
La disciplina de ingeniería que hay debajo
Para el lector técnico: la columna de entrega de once etapas, la arquitectura que comparte cada proyecto y las seis compuertas, cada una con la evidencia disponible hoy.
- 1AlinearEspecificar · GovernAhora
- 2DescubrirEspecificar · MapDespués
- 3DiagnosticarEspecificar · MapDespués
- 4PriorizarArquitectura · MapDespués
- 5DiseñarConstruir · MeasureDespuésTres leyes de dimensionamiento →Hoy frente a las leyes →
- 6GobernarConstruir · Governentrega
- 7PilotarEntregar · Measureentrega
- 8DesplegarEntregar · Manageentrega
- 9ProbarRevisar · MeasureDespués
- 10EscalarOperar y mejorar · ManageDespués
- 11AprenderOperar y mejorar · Governentrega
- Resultado de negocio
- Usuarios y stakeholders
- Proceso actual
- Flujo objetivo
- Alcance
- Requisitos no funcionales
- Requisitos de datos
- Clasificación de riesgo
- Criterios de aceptación
- Supuestos comerciales
- Límites del sistema
- Roles de agentes
- Flujos de datos
- APIs
- Identidad
- Permisos
- RAG / fuentes de conocimiento
- Puntos de decisión humana
- Modos de fallo
- Monitorización
- Modelo de despliegue
- Controles de seguridad
- Flujos principales
- Integraciones
- Herramientas de agentes
- Permisos
- Experiencia de usuario
- Registro
- Harness de pruebas
- Configuración
- Documentación
- Requisitos funcionales
- Seguridad
- Tratamiento de datos
- Comportamiento de prompts y modelos
- Casos de fallo
- Escalación humana
- Coste y latencia
- Aceptación de usuario
- Preparación operativa
- En la infraestructura del cliente
- Claves y entornos aprobados
- Con monitorización
- Con rollback
- Con runbooks
- Propiedad transferida
- Adopción
- Finalización de tareas
- Precisión
- Excepciones
- Coste
- Latencia
- Incidentes
- Valor de negocio
- Oportunidades de mejora
Etapa 3 · Model → Etapa 4 · Govern
Después, los controles, sus responsables y la evidencia de que se sostienen.