¿Por qué yeshcube diseña AI-native los productos que incorporan inteligencia artificial?

AI-native es un principio arquitectónico según el cual las capacidades de inteligencia artificial, los datos que las sostienen y los mecanismos para evaluarlas se definen desde el inicio del sistema. En yeshcube, el término describe una decisión interna de diseño para soluciones cuya función depende de modelos algorítmicos.

El principio organiza requisitos técnicos, científicos y de gobernanza dentro de un mismo ciclo de vida. La eficacia, la seguridad, el cumplimiento normativo y el impacto positivo requieren evidencia y controles específicos.

Alcance del concepto AI-native

El término AI-native se utiliza con matices distintos según el sector. Ericsson lo define en telecomunicaciones como la integración de capacidades de IA fiables en el diseño, el despliegue, la operación y el mantenimiento del sistema.

yeshcube adopta una definición operativa compatible con ese enfoque. Una solución se considera AI-native cuando su función central depende de capacidades de IA previstas desde la formulación de requisitos, junto con sus datos, límites, métricas y mecanismos de supervisión.

La categoría describe la arquitectura. Un sistema AI-enabled incorpora una función de IA a una infraestructura existente. Un sistema AI-native se estructura desde el comienzo alrededor de esa función.

Aspecto	AI-enabled	AI-native
Punto de partida	Sistema existente al que se incorpora una capacidad de IA	Sistema definido desde el inicio alrededor de una capacidad de IA
Dependencia funcional	La IA amplía una función existente	La capacidad de IA es central para la función prevista
Evaluación	Se adapta a una arquitectura ya construida	Se define junto con los requisitos y los riesgos
Gobernanza	Se integra en procesos preexistentes	Forma parte del ciclo de vida previsto para el sistema

La distinción es descriptiva. La arquitectura adecuada depende del propósito, del contexto de uso, del nivel de riesgo y de la necesidad real de emplear IA.

Requisitos desde la definición del sistema

Una arquitectura AI-native obliga a formular varias preguntas antes de elegir modelos o interfaces. Deben definirse el problema, la población o contexto de uso, las decisiones que apoyará el sistema y las consecuencias de una respuesta incorrecta.

También deben establecerse los límites funcionales. Esto incluye las tareas que el sistema puede ejecutar, las que requieren intervención humana, las condiciones de retirada y los comportamientos que quedan fuera de alcance.

La evaluación se diseña en paralelo. Las métricas técnicas, los criterios de utilidad, los riesgos previsibles y las condiciones de validación deben corresponder al uso previsto. Una métrica de precisión aislada resulta insuficiente cuando el sistema influye en personas, procesos sensibles o decisiones con efectos relevantes.

Datos, modelos y trazabilidad

El diseño AI-native trata los datos como parte de la arquitectura. Deben documentarse su procedencia, base jurídica cuando contengan datos personales, transformaciones, criterios de calidad, limitaciones y posibles sesgos.

La trazabilidad también abarca los modelos y la configuración del sistema. Según el caso, puede incluir versiones de modelos, instrucciones, herramientas disponibles, parámetros, conjuntos de evaluación, cambios de comportamiento y registros de incidentes.

El AI Risk Management Framework de NIST organiza la gestión del riesgo mediante las funciones de gobernar, contextualizar, medir y gestionar. El marco plantea una actividad continua durante todo el ciclo de vida y ofrece una referencia útil para estructurar responsabilidades y controles, aunque su uso es voluntario.

La documentación permite reconstruir qué sistema actuó, con qué configuración, sobre qué información y bajo qué reglas de supervisión. La explicabilidad requiere métodos adicionales adecuados al modelo y al uso previsto.

Arquitectura modular e interoperabilidad

Los componentes de una solución AI-native pueden separarse para reducir acoplamientos y facilitar su evaluación. El modelo, las fuentes de contexto, las herramientas, las políticas de acceso y la interfaz pueden evolucionar con ritmos diferentes si sus contratos están definidos.

Model Context Protocol es un ejemplo de protocolo para intercambiar contexto y exponer herramientas mediante una arquitectura cliente-servidor. La documentación oficial de MCP describe mecanismos de descubrimiento de capacidades, recursos, herramientas y transporte.

MCP puede apoyar la interoperabilidad en determinados sistemas. La autorización, la privacidad, la seguridad de las herramientas y el control de acciones requieren medidas específicas. Cada integración necesita restricciones de acceso, validación de entradas y salidas, gestión de credenciales, registro de actividad y revisión de su superficie de ataque.

yeshcube considera este tipo de protocolos como opciones arquitectónicas que deben evaluarse en cada solución. La implantación de MCP debe confirmarse en la documentación específica de cada producto o proyecto.

Aplicación en la arquitectura Somia

Somia es una arquitectura de inteligencia artificial de yeshcube que puede integrarse en productos y soluciones propios o de terceros. El principio AI-native establece que cada integración debe definir desde el inicio el propósito de la IA, los datos necesarios, los límites de actuación y los mecanismos de evaluación.

Una integración concreta puede utilizar conversación, audio, contexto u otras modalidades cuando estén documentadas para ese producto. Las funciones de detección emocional, personalización, autonomía o adaptación en tiempo real deben confirmarse en la documentación específica.

Somia Within identifica integraciones de Somia en soluciones de terceros. El alcance técnico y las garantías de cada integración deben describirse en su documentación específica. La eficacia requiere evaluaciones aplicables al caso de uso.

Evaluación científica y Escala ERL

El diseño AI-native facilita que las preguntas de evaluación se formulen antes del despliegue. Esta anticipación puede mejorar la correspondencia entre hipótesis, datos, métricas y arquitectura. Los resultados favorables siguen siendo una cuestión empírica.

La Escala ERL se utiliza en yeshcube para ordenar la preparación de la evidencia. El nivel de una solución solo debe declararse cuando exista una evaluación documentada. La arquitectura AI-native, como principio de diseño, no acredita un nivel propio; el de cada solución o integración concreta corresponde a su evaluación documentada.

En sistemas con impacto humano, la evaluación puede abarcar varias dimensiones:

• Rendimiento técnico en condiciones definidas.
• Robustez ante errores, cambios de distribución y entradas adversas.
• Calidad y representatividad de los datos.
• Utilidad para el objetivo previsto.
• Riesgos para privacidad, seguridad y derechos.
• Capacidad de supervisión, corrección y retirada.
• Resultados observados en la población y el contexto evaluados.

Los resultados deben indicar la fuente, la población, el contexto, el método y las limitaciones. Un prototipo funcional, una colaboración, una selección o un premio documentan esos hechos. La eficacia, la seguridad y la madurez científica requieren evidencia específica.

Gobernanza y responsabilidad

Una arquitectura AI-native requiere responsabilidades asignadas durante el desarrollo y la operación. Debe quedar claro quién aprueba los requisitos, quién puede modificar el sistema, quién revisa los incidentes y quién decide su suspensión.

Los registros de decisiones permiten documentar elecciones sobre datos, modelos, proveedores, métricas y riesgos aceptados. Los controles de cambio ayudan a determinar cuándo una modificación exige repetir pruebas o revisar el uso previsto.

La supervisión humana debe diseñarse para la tarea concreta. Su existencia formal resulta insuficiente cuando la persona responsable carece de información, tiempo, autoridad o medios para intervenir.

Privacidad desde el diseño

Cuando una solución trata datos personales, el AI-native debe coordinarse con las obligaciones del Reglamento General de Protección de Datos. El artículo 25 del RGPD exige integrar medidas técnicas y organizativas desde la determinación de los medios de tratamiento y aplicar la minimización de datos.

Una evaluación de impacto relativa a la protección de datos puede ser obligatoria cuando el tratamiento entrañe un alto riesgo para los derechos y libertades. El tratamiento previsto determina la necesidad de realizarla. La etiqueta AI-native carece de efecto jurídico sobre esa obligación.

La anonimización, el cifrado y los controles de acceso son medidas de protección posibles dentro de una arquitectura AI-native. Su aplicación depende de la implementación confirmada de cada solución de yeshcube.

Relación con el Reglamento de IA de la Unión Europea

El Reglamento de IA de la Unión Europea adopta un enfoque basado en el riesgo. El propósito previsto y el contexto de uso determinan la clasificación regulatoria.

Para los sistemas clasificados como de alto riesgo, el Reglamento contempla requisitos sobre gestión de riesgos, gobernanza de datos, documentación técnica, registros, transparencia, supervisión humana, precisión, robustez y ciberseguridad. Algunas obligaciones de transparencia se aplican también a determinados sistemas que interactúan con personas.

Diseñar esos elementos desde el inicio puede reducir incompatibilidades posteriores. El cumplimiento debe evaluarse para cada sistema, función y despliegue, con atención a la normativa sectorial que también resulte aplicable.

Riesgos y límites

Una dependencia estructural de la IA puede aumentar el impacto de fallos del modelo, datos inadecuados, cambios de proveedor o degradación del rendimiento. También puede ampliar la superficie de ataque cuando el sistema accede a herramientas, fuentes externas o acciones automatizadas.

Otros riesgos incluyen opacidad, automatización excesiva, sesgos, extracción de datos innecesaria y dificultad para reproducir resultados. Los controles deben ser proporcionales al daño posible y al grado de autonomía del sistema.

El diseño AI-native necesita estrategias de contingencia. Estas pueden incluir limitación de capacidades, supervisión humana, pruebas antes de cada cambio, monitorización, reversión de versiones y retirada temporal. Su presencia debe verificarse en la documentación de cada solución.

Criterio arquitectónico de yeshcube

yeshcube aplica AI-native para coordinar arquitectura, evidencia y gobernanza desde la definición de una solución que incorpora inteligencia artificial. El principio sirve para formular requisitos y responsabilidades antes de que los modelos se integren en un producto o servicio, y no alcanza a los desarrollos en los que la IA no interviene.

Su valor depende de la ejecución. La calidad del sistema debe demostrarse mediante documentación, evaluación, seguimiento y controles adecuados al contexto. El término AI-native funciona como criterio de diseño. Los resultados requieren validación.

Referencias

• Ericsson, A detailed study of the AI Native concept
• NIST, Artificial Intelligence Risk Management Framework
• Unión Europea, Reglamento de Inteligencia Artificial
• Unión Europea, Reglamento General de Protección de Datos
• Model Context Protocol, documentación de arquitectura

Descubre nuestro programa Allies →

Rellena nuestro Formulario de Contacto →