// NIJITECH · TECNOLOGÍA NÚCLEO
La orquestación de modelos es el trabajo de verdad para llevar la IA a producción, no solo mandar una petición a un modelo. El trabajo real es decidir qué modelo se ejecuta, verificar la salida y poder mostrar de dónde salió el resultado. niji core es el nombre de esa capa.
niji core es la columna vertebral de IA compartida sobre la que funcionan los productos de nijitech y las soluciones de cliente. Convierte la entrada en una representación común, decide qué modelo se ejecuta según el tipo de tarea (orquestación de modelos), verifica la salida que produce y la liga a su origen. Los datos se procesan en la región de la Unión Europea; las decisiones críticas pasan por aprobación humana.
00 — EL CONCEPTO
La orquestación de modelos es la gestión de varios modelos de IA sobre un mismo pipeline. El sistema decide qué modelo se ejecuta según el tipo de entrada y los requisitos de la tarea, procesa el resultado y produce una única salida coherente.
Clasificar un texto en una de dos categorías y ejecutar un análisis de varios pasos no exigen la misma capacidad. Poner el modelo más potente en cada tarea es como alquilar una excavadora para clavar un clavo: funciona, pero el coste no tiene sentido.
El coste de una llamada al modelo es pequeño por transacción, pero se multiplica con el volumen. En un sistema que hace diez mil llamadas al día, enviar la mitad de las tareas a un modelo más pequeño significa una factura visiblemente menor y una latencia visiblemente menor.
Un sistema construido sobre un único proveedor de modelos queda expuesto a sus cambios de precio, sus límites de cuota y sus cambios de política. La capa de orquestación afloja ese lazo: cambia el modelo, el pipeline se mantiene.
El mejor modelo de hoy puede estar en segundo lugar dentro de seis meses. Cambiar una llamada al modelo enterrada en el código de la aplicación es siempre trabajo de desarrollo; el mismo cambio en la capa de enrutamiento es trabajo de configuración.
01 — CÓMO FUNCIONA
El pipeline se ejecuta en el mismo orden en cada producto; lo que cambia es qué es la entrada y en qué se convierte la salida.
Audio, texto y señales de sistema: tres formatos, un solo flujo.
El audio de una reunión, el mensaje de WhatsApp de un cliente y un feed de precios de marketplace no se parecen en nada. La capa de entrada los convierte en una representación común: el audio se vuelve texto, el texto libre se estructura, las señales de sistema se encolan con marca de tiempo. Las capas siguientes no necesitan saber de dónde vino cada cosa.
Qué tarea va a qué modelo: lo decide el sistema.
Enviar cada tarea al modelo más potente sale caro; enviarlas todas al más barato produce respuestas erróneas. La capa de enrutamiento mira el tipo y los requisitos de la tarea y decide qué modelo se ejecuta. Para una clasificación corta basta un modelo pequeño, mientras que para un razonamiento de varios pasos entra uno más capaz. Esa decisión no es fija: cambia con los resultados de la medición.
La salida del modelo nunca se usa en bruto; primero pasa un control.
El modelo produce un resultado, pero ese resultado no llega en bruto al usuario. Si la salida se ajusta al formato esperado, si es coherente con su origen, si está por encima del umbral de confianza: todo eso se comprueba. La salida por debajo del umbral se regenera o se manda a aprobación humana. La defensa real contra la alucinación está en esta capa.
Un resumen, una puntuación, un emparejamiento, y el origen de cada uno.
La salida depende del producto: un resumen de reunión, una puntuación de rentabilidad, un emparejamiento de conductor. Lo que no cambia es que cada salida queda ligada a su origen. De qué frase salió un resumen, de qué datos se deriva una puntuación: todo queda registrado. Sin ese vínculo no es posible ni la auditoría ni la reclamación.
02 — CUATRO PRINCIPIOS
Los cuatro son decisiones; cada una tiene un coste y una razón. Hemos escrito ambas cosas abajo.
En una instalación on-premise los datos permanecen dentro de su propia infraestructura y no salen de ella. En uso en la nube, el tratamiento se realiza en las regiones de EE. UU. y la UE; a las transferencias internacionales se les aplican las garantías del art. 9 de la KVKK. La lista completa de subencargados está en el Anexo C del Anexo de Tratamiento de Datos.
El artículo 9 de la ley turca de protección de datos (KVKK) somete las transferencias transfronterizas al consentimiento y a garantías; el RGPD trata la residencia de los datos como condición básica de auditabilidad. Una instalación on-premise cumple ambas sin entrar siquiera en un debate sobre transferencias: los datos nunca salen de la organización. En uso en la nube, el tratamiento se realiza en las regiones de EE. UU. y la UE y a la transferencia se le aplican las garantías del artículo 9.
Las llamadas al modelo pasan por infraestructura on-premise o en la nube. Cuando el equipo legal del comprador pregunta « ¿adónde van los datos? », la respuesta es una frase.
Cada resultado queda ligado al origen del que salió.
No se puede reclamar contra una salida de caja negra. Si no puedes mostrar por qué el resultado es el resultado, no puedes depurarlo, no puedes auditarlo y el usuario no confiará en el sistema. La explicabilidad es una elección de arquitectura, no una función de informes.
Cada elemento de un resumen de reunión se remonta a una frase de la transcripción, una puntuación de producto a los datos de demanda y competencia que hay detrás, un desplazamiento de presupuesto al cambio de rendimiento que lo provocó.
Las decisiones críticas pasan por aprobación humana antes de salir.
Las decisiones totalmente autónomas tienen sentido cuando el coste de un error es bajo. Para acciones caras de deshacer — emitir una factura, enviar una respuesta al cliente, mover presupuesto — el paso de aprobación no es una carencia del sistema sino su salvaguarda.
Qué decisiones requieren aprobación se fija en el diseño: un umbral previsto desde el principio, no un control añadido después.
El procesamiento se ejecuta cerca del usuario.
En un sistema en tiempo real, la latencia importa tanto como la precisión. Un resumen que llega mientras la reunión sigue en marcha se vuelve inútil con dos segundos de retraso. Cada petición que viaja a una región lejana y vuelve se come ese margen.
Las operaciones ligeras se ejecutan cerca del usuario; la inferencia pesada se deja a la capa central. Ese reparto reduce a la vez la latencia y el coste.
03 — CUMPLIMIENTO EMPRESARIAL
El cumplimiento es trabajo de arquitectura, no de papeleo. La tabla siguiente muestra qué requisito legal cumple cada decisión de diseño.
| Requisito | Base | Respuesta arquitectónica |
|---|---|---|
| Los datos no deben salir del país | KVKK art. 9 | El tratamiento se realiza on-premise o en la nube. |
| Las decisiones automatizadas deben poder impugnarse | RGPD art. 22 | Aprobación humana en decisiones críticas; cada salida ligada a su origen. |
| El tratamiento debe ser auditable | KVKK art. 12 · RGPD art. 30 | La cadena de entrada, decisión de enrutamiento y salida queda registrada y es rastreable. |
| Minimización de datos | KVKK art. 4 · RGPD art. 5 | Los plazos de conservación se definen en el contrato; el almacenamiento indefinido no es lo predeterminado. |
| Los datos no deben usarse para otros fines | Limitación de la finalidad | No por defecto. Hay dos excepciones: en trabajos de prueba de concepto, cuando la empresa participante ha dado su permiso por escrito; y para el desarrollo de la plataforma propia de un cliente, a petición de ese cliente. Fuera de estos casos los datos de cliente no se usan para entrenar modelos, y un modelo entrenado con los datos de un cliente no da servicio a otro. |
04 — QUÉ FUNCIONA SOBRE ÉL
Si una arquitectura funciona solo se ve cuando se prueba en problemas distintos. Los dieciséis productos de abajo hacen cosas muy diferentes y aun así corren sobre el mismo pipeline.
nijibotAudio → transcripción → resumen → acción
WhatsModMuchos canales → una bandeja → respuesta aprobada
AMZAIPlusFicha → precio → Buy Box
Amz CalculusDemanda + competencia + coste → rentabilidad
cep taxiUbicación + demanda → emparejamiento → pago
OtoWosPlazos + depósito en garantía + archivo legal
AdMostRendimiento → reparto del presupuesto → ROAS
PylunCadena compatible con EVM + capa DeFi
CMDeskAcceso remoto → SSH → despliegue masivo
KovanlyMáquinas virtuales → red → copia de seguridad
LattixRed entre pares → cifrado de extremo a extremo
HiriCantera de candidatos → puntuación → aprobación humana
Global Company ServiceDocumentos → constitución → banca y alta fiscal
Tera LIVEDirecto → sala de voz → economía de regalos
Exporia.ioCatálogo → lista de compradores → secuencia comercial
Yeşil DünyaMedición → atribución de origen → seguimiento de reducciónTÉRMINOS
En lugar de repetir aquí las definiciones, las mantenemos en un solo sitio en el glosario.
PREGUNTAS FRECUENTES
niji core es la columna vertebral de IA compartida sobre la que funcionan los productos de nijitech y las soluciones de cliente. Recibe la entrada, decide qué modelo se ejecuta, verifica la salida y la liga a su origen. Todos los productos usan el mismo núcleo.
En la práctica describen la misma idea: gestionar varios modelos sobre un mismo pipeline. « Orquestación de modelos » subraya la decisión de qué modelo se ejecuta; « orquestación de IA » subraya el conjunto de modelos, herramientas y flujos de datos. niji core cubre ambas capas.
No estamos atados a un solo modelo. Según el tipo de tarea entran modelos distintos, y esa elección puede cambiar con los resultados de la medición. La independencia de modelo es una decisión deliberada: una arquitectura dependiente de un proveedor queda expuesta a sus cambios de precio y de política.
Hay una defensa de tres capas. La salida se comprueba contra el formato esperado; se verifica su coherencia con el origen; los resultados por debajo del umbral de confianza se regeneran o se mandan a aprobación humana. Además, ligar cada salida a un origen hace visible un resultado inventado.
El enfoque por defecto es la recuperación, no el entrenamiento: dejamos que el modelo alcance tus datos en el momento de la consulta (RAG). Como los datos no quedan horneados en el modelo, se mantienen actualizados y sigue siendo posible retirarlos. Los casos que realmente necesitan entrenamiento a medida se evalúan aparte.
La precisión se mide por tarea, y cada proyecto construye su propio conjunto de evaluación. Una afirmación fija de « x por ciento de precisión » no significa nada si no se dice en qué tarea y sobre qué datos se midió. La métrica la acordamos juntos durante el descubrimiento.
Para eso está la capa de integración. Construimos conexiones que funcionan con calendarios, CRM, mensajería y sistemas contables. Con qué sistema conectas — y si es técnicamente posible — queda claro durante el descubrimiento.
Para preguntas generales, ver la página de FAQ · para nuestros servicios, ver soluciones empresariales
EMPEZAR
En una llamada de descubrimiento vemos juntos cuál de tus trabajos encaja en este pipeline.
Reservar una llamada de descubrimiento →Nos gustaría usar Google Analytics para entender cómo se utiliza el sitio. Esta herramienta instala cookies y transfiere datos a Estados Unidos. Si lo rechaza, el sitio funciona exactamente igual.
