Cómo trabajamos,
para cada oferta.

El encuadre en SDEN no es una llamada de descubrimiento. Es una investigación estructurada que produce un enunciado de problema escrito que nombra la verdadera tarea que el software debe cumplir, una arquitectura y un registro de decisiones que explica las opciones técnicas que recomendamos (y las alternativas que consideramos), y un registro de riesgos que clasifica lo que podría salir mal según la explotabilidad y el impacto de negocio. Para el trabajo de IA va más lejos: una lectura honesta de la viabilidad (¿es un problema que un modelo puede resolver de forma fiable, o un motor de reglas disfrazado de IA?), una decisión de construir-o-comprar frente a las soluciones de catálogo, y un examen de si tus datos están realmente listos para alimentar un modelo. La fase termina con una recomendación de seguir / no seguir que estamos dispuestos a defender ante tu consejo.

Hacemos las preguntas que otros proveedores se saltan. ¿Quién es el decisor responsable de tu lado? ¿Cómo es el trabajo para el usuario el día después del lanzamiento, y no durante la demo? ¿Qué datos crea el producto, dónde residen y quién tiene derecho a verlos, y dónde se sitúan en los niveles de riesgo del Reglamento Europeo de IA? Sobre todo: ¿qué significa «bueno», medido? Definimos los criterios de evaluación aquí, en la primera fase, para que «funciona» sea una cifra acordada en lugar de una impresión en la demo. La fase es pagada, acotada en el tiempo y corta, normalmente de una a tres semanas según el alcance.

Una demo es un vídeo. Un prototipo es algo que el usuario puede usar de verdad, sobre la forma real de los datos, sobre el stack exacto que entregaremos en producción. La segunda fase entrega lo segundo. El equipo diseña los recorridos esenciales, construye un prototipo interactivo para los caminos de mayor riesgo (los que determinan si el producto es usable, no los que determinan si es bonito), y los valida sobre datos reales y con usuarios reales antes de que se ponga una sola línea de código de producción.

Para la IA, aquí es donde se toman y se documentan las decisiones de mayor peso: qué modelo, y por qué; la recuperación aumentada (RAG) frente al fine-tuning frente a un simple prompt; una sola llamada frente a un agente; y el presupuesto de coste y latencia en el que cada enfoque debe encajar. Nos inclinamos hacia la tecnología aburrida bajo la IA (frameworks, bases de datos y alojamiento que la comunidad ya ha depurado a gran escala) y nombramos la razón de cada elección. La fase también diseña el banco de evaluación: el conjunto de tests puntuado que nos dirá, de forma automática y en cada cambio, si la IA mejora o se degrada. Produce el prototipo, un sistema de diseño (tokens, componentes, línea base de accesibilidad) y ese plan de evaluación y de tests para la fase de producción.

El desarrollo en SDEN se desarrolla en iteraciones de dos semanas, con una versión funcional al final de cada una. Cada pull request es revisada por un segundo ingeniero antes del merge; la barrera de merge ejecuta la suite de tests, la suite de evaluaciones de la segunda fase, los analizadores de seguridad (SCA, SAST, detección de secretos) y el verificador de tipos. La protección de ramas está activada, los commits firmados están activados, y ningún ingeniero, ni el más experimentado, puede saltarse las comprobaciones. El resultado es una base de código donde el segundo ingeniero que lee un archivo ya lo entiende, y donde un cambio que degrada en silencio la IA hace fallar la integración continua en lugar de llegar a producción.

El endurecimiento es la parte que la mayoría de proveedores se saltan. Es el trabajo que convierte «funciona» en «funciona en producción durante los próximos tres años». Para la IA, eso significa guardarraíles en las entradas y las salidas, topes de coste para que un bucle desbocado no pueda arruinar la funcionalidad, y una revisión de seguridad contra la inyección de prompt y el OWASP LLM Top 10, además del OWASP Top 10 y el nivel ASVS pertinente. También incluye los tests de carga contra los perfiles de tráfico esperados, los tests de caos sobre los modos de fallo que el registro de riesgos señaló en la primera fase, y la cláusula de ausencia de deuda técnica: no entregaremos código por el que no estaríamos dispuestos a recibir una alerta a las 3 de la madrugada. Si un plazo fuerza un atajo, el atajo aterriza en el seguimiento de incidencias como un P0, y se devuelve antes de que llegue la próxima funcionalidad. Documentamos explícitamente esta disciplina en nuestra postura de ingeniería de la seguridad.

La entrega es escalonada. La primera puesta en producción aterriza tras un feature flag, para un solo inquilino o una pequeña cohorte de usuarios. Supervisamos los SLO (y, para la IA, las cifras de calidad y de coste) contra tráfico de producción real durante una ventana de observación definida, y luego ampliamos a la audiencia completa una vez los datos confirman que el sistema se comporta como se esperaba. La puesta en producción no es un evento de calendario: es un cambio de estado medible.

Lo que entregamos con la versión es lo que hace el proyecto duradero: un runbook para cada tarea operativa, un panel de supervisión que expone los SLO que nos comprometimos a respetar así como el comportamiento de la IA en producción (calidad, deriva, tasa de alucinación y gasto, no solo la disponibilidad), un plan de guardia para los incidentes que el registro de riesgos anticipó, una plantilla de respuesta a incidentes, y documentación escrita para el siguiente ingeniero que se incorpore a tu equipo. Crucialmente, el traspaso transfiere la IA misma: los prompts, la suite de evaluaciones y los guardarraíles, para que tu equipo pueda modificar el sistema de forma segura, y no solo mantenerlo en marcha. Los proyectos de SDEN no terminan en la puesta en producción: se difuminan. Nos comprometemos a una ventana de soporte definida tras el lanzamiento (normalmente de tres a seis meses, calibrada al proyecto) durante la cual operamos el sistema conjuntamente con tu equipo, y durante la cual se transfiere el conocimiento operativo, no solo el código.