IA y sistemas inteligentes

Los agentes de IA no son software normal.

Misma entrada, distinta salida. Generalizan más allá de su especificación — eso es la capacidad y el modo de fallo. Llevarlos a producción exige otra disciplina y otro conjunto de herramientas.

Ambas cosas son lo que hacemos.

O compruébalo funcionando: ejecuta el AI Opportunity Scan gratuito. Menos de dos minutos. Una URL.

Otro tipo de software

La corrección deja de ser binaria.

Casi todas las prácticas de ingeniería en las que confía tu equipo asumen que la corrección es un estado: el código está bien o está mal, y un test te dice cuál. Los sistemas aprendidos por máquina no funcionan así. La corrección es una distribución — una tasa de falsos positivos es una propiedad del sistema, no un defecto suyo. Los agentes generativos lo llevan al extremo: son no deterministas por diseño, así que la misma entrada no produce de forma fiable la misma salida dos veces.

01 · Lo que ganas

Comportamiento más allá de la especificación.

El software determinista resuelve los casos que alguien enumeró. Un agente resuelve los que nadie escribió — formatos de documento no vistos, formulaciones imprevistas, la cola larga que antes exigía un motor de reglas imposible de mantener. Problemas que antes no se podían especificar pasaron a ser abordables. Esa es la razón para usar uno.

02 · Lo que aceptas

La misma propiedad, invertida.

Un sistema que generaliza más allá de su especificación a veces actuará fuera de ella — y falla de otra manera. El software tradicional falla a gritos: una excepción, un 500, un build en rojo. Un agente falla de forma plausible — bien formado, seguro de sí mismo, equivocado, sin que nada levante una bandera. Puede fallar en tres de cada cien ejecuciones, así que no es reproducible a demanda, y arreglarlo no es corregir código: es desplazar una distribución. Por eso una suite de regresión es infraestructura, no higiene.

03 · Lo que cambia sin ti

El suelo se mueve.

Con un modelo alojado, tu proveedor publica una actualización y el comportamiento cambia — sin deploy, sin commit, sin ticket. Con pesos propios el modelo se queda quieto, pero el mundo no: las distribuciones de entrada derivan y la precisión del trimestre pasado se degrada sin que nada cambie en tu stack. Por eso una suite de regresión es infraestructura, no higiene.

04 · En qué se convierte la superficie de ataque

Datos que pueden actuar.

En otros sitios, los datos son datos y las instrucciones son instrucciones. En un agente, cualquier cosa que llegue a la ventana de contexto — un documento, un correo, la respuesta de una herramienta — puede comportarse como una instrucción. La inyección de prompts no es una subclase de la validación de entradas; tu revisión de seguridad no tiene una casilla para ella. Es específico de los agentes: la única propiedad de esta lista de la que escapa un sistema de visión o de ML tabular.

No se puede hacer un test unitario de una distribución.

La confianza viene de evaluar contra conjuntos de datos curados, puntuar trazas reales de producción y poner puertas de regresión que se ejecutan cada vez que cambia el modelo — no de porcentajes de cobertura. Otro software, otros fallos, otras herramientas.

Modo de fallo 01 · 0 comprobaciones

Sin arnés de evaluación.

Cada cambio de prompt, actualización de modelo o nuevo tipo de documento es una apuesta. Sin evaluaciones de regresión nadie puede decir si el arreglo de ayer rompió los casos del mes pasado — así que los cambios se congelan y el prototipo se fosiliza.

Modo de fallo 02 · 1 paso · 5 tareas

El agente monolítico.

Un prompt haciendo cinco tareas. Demuestra de maravilla y se depura fatal: cuando cae la calidad de salida, no hay forma de aislar qué responsabilidad falló. Los sistemas que no se pueden depurar no llegan a producción.

Modo de fallo 03 · precisión ↓ con volumen

Colapso de contexto con volumen real.

El prototipo corría sobre cincuenta documentos escogidos a mano. Producción significa cientos de miles — mal formados, duplicados, contradictorios. La recuperación se degrada, las estrategias de memoria que funcionaban en la demo se vienen abajo y la precisión se desliza en silencio.

Modo de fallo 04 · gasto ↑ compuesto

La curva de coste que nadie modeló.

Costes de tokens que parecían insignificantes por petición se acumulan entre reintentos, bucles de agentes y escala. Los proyectos mueren en el despacho del director financiero tan a menudo como en el repositorio.

Modo de fallo 05 · sin camino de vuelta

Sin vía de escape.

Sin rollback, sin escalado a una persona, sin registro de auditoría. En el momento en que el sistema comete un error caro sin historia de recuperación, la confianza se evapora — y la confianza no vuelve a precio de prototipo.

Por qué mueren los prototipos

La brecha tiene una anatomía.

El no determinismo es la causa. Estos son los síntomas. Todos los proyectos de IA atascados a los que nos han llamado fallaron de una de unas pocas formas predecibles — fallos de ingeniería, no de estrategia.

Firma del fallo0 comprobaciones

ingerir

clasificar

extraer

decidir

confirmar

sin comprobación

todos los pasos se ejecutan, ninguno se verifica — cambia uno y no sabrás qué se movió

Un pipeline · cinco formas de fallar

Cómo empieza un proyecto

Dos preguntas, respondidas con artefactos.

Tu problema

01 · Evaluar

02 · Diseñar

Empieza la construcción →

Ocho entregables · sigue bajando o elige uno

Antes de que arranque cualquiera de las cuatro prácticas, ambas se resuelven en código que funciona y contratos escritos — no en diapositivas. Todo eso es tuyo, construyamos el sistema o no.

01 · Evaluar¿merece la pena construirlo?

Prueba de viabilidadCódigo funcionando sobre tus datos reales, no una diapositiva que afirma que es viable.

Qué te diceQué precisión tiene hoy, medida sobre tus documentos y no sobre un benchmark.Qué casos resuelve limpiamente y cuáles siguen necesitando a una persona.Qué debe cumplirse para que el sistema completo aguante en producción.

Software funcionandoLa decisión que resuelveSi merece la pena construirlo siquiera.

Mapa de oportunidades de IADónde genera palanca la IA en tus flujos de trabajo reales.

Qué te diceLos dos o tres puntos que conviene automatizar primero, y por qué.Los que parecen atractivos pero no compensan el esfuerzo.Cuánto vale cada uno al mes en horas o en gasto.

Entregable escritoLa decisión que resuelvePor dónde empezar y qué dejar de lado por ahora.

Diagnóstico de datosQué pueden sostener tus datos hoy y qué necesita enriquecimiento antes.

Qué te diceQué fuentes son utilizables tal como están.Dónde están los huecos, los duplicados y el histórico que falta.Cuánta preparación hace falta antes de poder fiarse de los resultados.

Entregable escritoLa decisión que resuelveSi los datos sostienen el plan, o el plan cambia.

Modelo de costesProyección de la economía de inferencia e infraestructura a tus volúmenes.

Qué te diceCoste por documento, petición o transacción al volumen de hoy.Cómo escala eso, incluidos los reintentos que la mayoría de estimaciones ignora.Alternativas más baratas y a qué renuncia cada una.

Modelo financieroLa decisión que resuelveSi la economía funciona a escala, no solo en un piloto.

02 · Diseñar¿qué es el sistema, exactamente?

Topología de agentesQué responsabilidades son agentes, cuáles código determinista y cómo se componen.

Qué te diceQué pasos necesitan de verdad un modelo — normalmente menos de los esperados.Qué pasos siguen siendo software convencional, para que sigan siendo predecibles y baratos.Dónde se reparte el trabajo para que un fallo se pueda rastrear a un solo sitio.

ArquitecturaLa decisión que resuelveQué vamos a construir, con precisión suficiente para estimarlo.

Contrato de flujo de datos e integraciónCómo se conecta el sistema a tu ERP, CRM, mensajería y almacenes de datos.

Qué te diceQué datos cruzan exactamente cada frontera, y en qué dirección.Qué pasa cuando un sistema va lento, se cae o envía lo mismo dos veces.Qué es responsabilidad de tu equipo y qué es nuestra.

Plan de integraciónLa decisión que resuelveCómo encaja esto en tu stack sin que ninguna parte bloquee a la otra.

Plan de evaluaciónLa suite de tests que filtrará todos los cambios futuros, diseñada antes de empezar a construir.

Qué te diceQué significa «suficientemente bueno para lanzar», como una cifra que todos aceptan.Cómo se detecta una actualización de modelo o de proveedor antes de que la noten tus usuarios.Cómo los problemas de producción se convierten en tests permanentes en vez de repetirse.

Plan de calidadLa decisión que resuelveCómo sabrás dentro de seis meses que sigue funcionando.

Diseño de guardrails y puntos de control humanosDónde el sistema debe ceder el paso, escalar o detenerse.

Qué te diceQué decisiones van a una persona, y con qué nivel de confianza.Qué no puede escribirse nunca en un sistema de negocio sin comprobar.Qué ocurre cuando algo va mal: escalar, revertir o parar.

Riesgo y controlesLa decisión que resuelveCuánta autonomía tiene el sistema el primer día.

La mayoría de los proyectos empiezan con una versión de dos minutos de la primera puerta. Inicia tu AI Opportunity Scan gratuito →

Cuatro prácticas, no cuatro pasos. La cuarta es la razón por la que las tres primeras siguen siendo ciertas.

Sistemas de IA multiagente

Constrúyelo

Sistemas de agentes orquestados con los guardrails, la monitorización y la disciplina de coste que les permiten funcionar sin supervisión.

Llegas con

Un notebook que funciona, un piloto de un solo equipo o una demo de proveedor que se quedó en «impresionante».

Construimos

La topología de agentes — orquestadores, agentes especialistas, pasos deterministas allí donde el determinismo gana — con uso de herramientas, memoria, puntos de control humanos y trazado diseñados desde el primer commit.

Te llevas

Un sistema desplegado, su suite de evaluación, sus trazas y la documentación que tu equipo necesita para ampliarlo.

Un criterio que aplicamos

Cuándo dividir un agente monolítico en un orquestador con especialistas — y cuándo no. Si el flujo es fijo, el código determinista gana siempre a un agente; los agentes se ganan su sitio solo donde el enrutado y el razonamiento son de verdad dinámicos. La mayoría de los proyectos atascados se equivocaron en esta frontera, en un sentido o en el otro.

LangChainAWS BedrockFireworks AITavily

Enriquecimiento de datos y ML

Aliméntalo

Los sistemas de IA valen lo que valen los pipelines de datos que tienen debajo — y el pipeline suele ser el proyecto de verdad.

Llegas con

Datos repartidos entre un ERP, hojas de cálculo, PDF y un flujo de sensores que nadie mira; o un prototipo RAG que responde con seguridad y se equivoca.

Construimos

Pipelines automatizados de enriquecimiento y ML — limpiar, conectar y activar tus datos para que los modelos trabajen sobre hechos fiables, con flujos programados que lo mantengan así. Eso incluye los datos de evaluación del sistema: ejemplos curados, trazas de fallo etiquetadas y golden datasets también son ingeniería de datos — y son justo los datasets que casi todos los equipos olvidan construir.

Te llevas

Pipelines en producción, contratos de datos documentados y flujos de reentrenamiento y actualización que tu equipo puede operar.

Un criterio que aplicamos

Cuándo enriquecer aguas abajo y cuándo arreglar los datos en origen. Los pipelines de enriquecimiento pueden tapar un proceso roto durante un tiempo — pero si el sistema de origen sigue produciendo basura, te diremos que arregles el origen, aunque el pipeline fuera la factura más grande.

LangGraphKestraAWS SageMakerAWS Glue

Cloud, edge y ubicación del modelo

Despliégalo

Desplegar donde están los datos, con el modelo que encaja — cloud de AWS cuando se puede, planta de producción cuando toca, pesos propios cuando lo exigen la economía o la privacidad.

Llegas con

Un sistema que funciona en un entorno y requisitos que ahí no puede cumplir — latencia, conectividad, residencia de datos o coste unitario. O una factura de API frontera que dejó de tener sentido a volumen de producción.

Construimos

Despliegue en producción sobre AWS, o inferencia en el edge donde se originan los datos — plantas de producción, vehículos, ubicaciones remotas — con resiliencia offline cuando la red es un quizá. Y la decisión de modelo por debajo: API frontera, modelo de pesos abiertos, ajustado o cuantizado para el hardware de destino.

Te llevas

Infraestructura como código, pipelines de despliegue, una decisión documentada sobre el origen del modelo con sus compromisos de coste y calidad, y una flota edge que tu equipo puede actualizar en remoto.

Un criterio que aplicamos

Cloud, edge o modelo propio es una decisión de economía y física, no una preferencia. Modelamos presupuestos de latencia, la conectividad real, la gravedad de los datos y el coste por inferencia a tus volúmenes. A veces un modelo pequeño ajustado sobre tu propio hardware gana a la API frontera en todos los ejes que te importan, salvo en el del gráfico del benchmark.

AWS GreengrassAWS SageMaker EdgeLambdasAWS Kinesis

Evaluaciones, observabilidad y rendimientoEl camino de vuelta

Monitorízalo

El sistema que se lanza es una hipótesis. La monitorización es cómo se convierte en un hecho — y sigue siéndolo.

Llegas con

Un sistema en producción que nadie puede demostrar que funciona. La calidad se mide en volumen de quejas, «va peor desde la actualización del modelo» es infalsable, y nadie sabe decir cuánto cuesta una petición ni cuánto se ralentizó el mes pasado.

Construimos

El arnés de evaluación y la capa de observabilidad. Suites de regresión offline que filtran cada release; evaluaciones en línea que puntúan trazas reales de producción donde no existe respuesta de referencia; trazado distribuido en cada paso de agente y llamada a herramienta; presupuestos de latencia y de coste en tokens medidos por paso del flujo en vez de estimados. Y el bucle que lo conecta todo — un fallo en producción se convierte en un modo de fallo con nombre, luego en un ejemplo del dataset, luego en cobertura de regresión permanente.

Te llevas

Una suite de regresión que crece con cada incidente, paneles de latencia p50/p95 y coste por flujo que tu equipo lee sin nosotros, alertas afinadas a modos de fallo con nombre en vez de a puntuaciones genéricas de calidad, y un procedimiento escrito para convertir el próximo fallo de producción en un test.

Un criterio que aplicamos

Qué fallos merecen un juez LLM y cuáles necesitan una comprobación determinista. Los jueces son seductores porque escalan a la calidad subjetiva, pero hay que calibrarlos contra trazas etiquetadas antes de que sus puntuaciones puedan filtrar un release — si no, solo llenan un panel. Todo lo que se pueda expresar como comprobación de esquema, coincidencia exacta o código de salida no debería dejarse nunca en manos de un modelo. Preferimos lanzar cincuenta aserciones deterministas baratas que un juez impresionante en el que nadie confía.

En una flota edge esto es otra disciplina distinta — salud de los dispositivos, versiones de firmware y deriva de sensores en hardware al que no puedes entrar por SSH.

LangSmithAWS Bedrock AgentCore

Cuatro prácticas, un bucle. Lo que Monitorízalo aprende en producción se convierte en lo que Constrúyelo cambia, lo que Aliméntalo cura y lo que Despliégalo saca a continuación. Un sistema sin ese camino de vuelta no está en producción — está suelto.

«¿No podría construirlo nuestro equipo?» Con casi total seguridad. La construcción es la mitad visible — el arnés, las trazas y el bucle son la mitad que decide si el año que viene sigue funcionando.

Por dentro de un sistema en producción

Qué significa «listo para producción», dibujado.

El mismo pipeline de documentos y sensores de nuestra portada — esta vez con las piezas que lo hacen productivo: el bucle de evaluación, las trazas, los puntos de control, los contadores.

Arquitectura de referencia · pipeline de documentos y sensoresDesplázate en horizontal para seguir el pipeline →

el camino de vuelta — fallo → ejemplo del dataset → cobertura de regresión

puerta de evals offline— no se fusiona ningún cambio hasta que la suite pasa, así que lo aprendido en producción decide lo que sale después

documentos

sensores

▶

ingerir

▶

orquestador

▶

clasificador

extractor de datos

validador

▶

revisión humana

erp

trazadomedición de costeevals en línea

Puerta de evals offline — cada clase de salida tiene una suite de regresión con ejemplos curados; los cambios de prompts o modelos no se fusionan hasta que la suite pasa.

Evals en línea — las trazas de producción se puntúan de forma continua frente a señales de calidad y de política, sin una respuesta de referencia en la que apoyarse; el equivalente en vivo de la puerta offline.

Trazado — cada decisión del agente emite una traza; cuando algo va mal, la respuesta está en la traza, no en una sala de crisis.

El camino de vuelta — una traza que expone un fallo se convierte en un modo de fallo con nombre, luego en un ejemplo del dataset, luego en cobertura de regresión permanente; esta flecha es lo que convierte el diagrama en un bucle en vez de un pipeline.

Punto de control humano — las salidas de baja confianza y alto riesgo van a revisión; el umbral es un parámetro ajustado, no una esperanza.

Medición de coste — el gasto se controla por paso del flujo; los reintentos y los bucles de agente están presupuestados, no se descubren.

Guardrails en las fronteras — validación de entrada al entrar, contratos de salida al salir; el ERP nunca recibe una escritura sin validar.

Contrato de integración — la frontera con el ERP es un esquema versionado, para que el sistema de IA y el de negocio puedan evolucionar por separado.

Dónde conecta el otro pilar

La IA necesita datos. Los datos necesitan sensores. Los sensores necesitan hardware.

Cuando los datos que tus modelos necesitan todavía no existen — porque están en una planta de producción, dentro de una máquina o al otro extremo de una red poco fiable — el proyecto deja de ser un problema de software. Nuestra división de hardware e IoT diseña el hardware que produce esos datos: PCB a medida, radios evaluadas en RF, presupuestos de energía medidos en microamperios. Un solo equipo, los dos extremos del pipeline.

Explora las capacidades de nuestro laboratorio →

Cuando tú quieras

Comprueba la disciplina antes de contratarla.

El AI Opportunity Scan es en sí mismo un sistema agéntico en producción — construido con la misma disciplina de evaluación, trazado y guardrails que describe esta página. Ejecútalo sobre la URL de tu empresa y obtén tu mapa de oportunidades de IA y tu brecha competitiva. Menos de dos minutos. Una URL.

Inicia tu AI Opportunity Scan gratuitoHabla con un ingeniero