Business API & AI · by Mobiconnect

Verificable por diseño.

La trazabilidad no es una capa añadida al final. Es una condición de diseño para autorizar, ejecutar, observar y evidenciar cada operación.

Conecta2 organiza Business API & AI sobre Open Telco, Open API, CAMARA y GSMA Open Gateway. El acceso y el cobro se resuelven mediante Entitlements; la capa web3 permanece deliberadamente opcional y nunca sustituye los controles del núcleo.

Solicitar piloto Revisar las APIs

Decisiones de arquitectura: 2026-10-22 · Disponibilidad productiva: [por validar] · Indicadores: NO MEDIDO

Paquete de evidencia Modelo definido

Solicitud con identificador trazable Definido

Evaluación de Entitlement y política [por validar]

Señal de red cuando el flujo la requiere [por validar]

Ejecución y referencia del proveedor [por validar]

Evidencia, retención y acceso auditables [por validar]

“Modelo definido” describe arquitectura. No declara integración, certificación ni disponibilidad productiva.

Principios de control

Una afirmación verificable exige contexto, referencia y trazabilidad

La interfaz separa la intención de diseño de la disponibilidad demostrada. No se presentan capacidades futuras como operativas ni se sustituye una prueba por una etiqueta visual.

Regla editorial: todo dato no acreditado se标记 como [por validar] o NO MEDIDO.

Control

Autorización antes de ejecutar

Ninguna capacidad de Open Telco, Open API, CAMARA o GSMA Open Gateway se considera concedida únicamente porque una carga útil sea válida. El estado del Entitlement y la política aplicable preceden a la ejecución.

Evidencia

Referencias, no afirmaciones

Cada resultado debe poder asociarse a una solicitud, una versión de política, una referencia del proveedor y un evento de ejecución. Los identificadores y su retención se configuran antes del piloto.

Seguridad

Mínimo privilegio por capacidad

Las credenciales, permisos y ambitos se limitan a la operación necesaria. LaBusiness API& AI orquesta; no eleva privilegios ni decide por sí sola la legitimidad de una solicitud.

Gobernanza

Normativa como configuración

Consentimiento, finalidad, retención, geographical aplicabilidad y revisión humana se expresan como políticas versionadas. Los criterios legales y regulatorios permanecen subjects a validación.

Compatibilidad

Adaptadores, no acoplamiento

Los proveedores de señal, red y modelos de IA se integran mediante contratos estables. La architecture no presupone cobertura, calidad, precio o disponibilidad de un tercero.

Opcionalidad

Web3 fuera del camino crítico

La capa web3 puede adjuntar proofs o referencias, pero no concede Entitlements, modifica políticas ni reemplaza la evidencia operativa del núcleo.

Arquitectura del portafolio

Decisiones vigentes desde el 2026-10-22

La arquitectura parte de Mobiconnect como plataforma de Business API & AI sobre Open Telco y Open API. CAMARA, GSMA Open Gateway y Entitlements-components forman parte de sus límites de integración; web3 es una extensión opcional.

Alcance de esta página

Describe controles, contratos y estados de validación. No afirma certificación, cobertura comercial, rendimiento ni operación productiva. Esos elementos siguen en estado [por validar].

Plataforma única

Mobiconnect articula Business API & AI sobre Open Telco y Open API. Conecta2 expone una experiencia de producto sin multiplicar la autoridad técnica.

Entitlements como control

La autorización, el consumo y el cobro se.linkean a Entitlements configurables. El modelo comercial y la conciliación permanecen [por validar].

Web3 estrictamente opcional

Ninguna transacción, wallet, credential o red blockchain es requisito para operar el núcleo. Su adopción exige un adaptador y una justificación separate.

Legal configurable

Las políticas se versionan, asocian a cada decisión y pueden ajustarse por jurisdicción, producto yfinalidad sin reescribir el núcleo.

Límites del sistema

La IA solicita; el control autoriza

Un modelo puede interpretar una intención, preparar una solicitud o proponer una acción. No puede conceder una capacidad de red, aceptar sus propias condiciones, eludir un control ni convertir una inferencia en consentimiento.

El Control Plane decide con Entitlement, política y contexto de confianza.
El Data Plane ejecuta la capacidad autorizada mediante adaptadores.
El Evidence Plane conserva referencias y metadatos según política.
La capa web3 es un adaptador externo y descartable.

Experiencia y APIInterfaces

Conecta2 Web Business API Developer API

OrquestaciónProcesamiento

Intención Validación Policy decision AI adapter

Control PlaneDecisión

Entitlements Consentimiento Riesgo Idempotencia

Network AdaptersEjecución

Open Telco Open API CAMARA GSMA Open Gateway

Evidence PlaneTrazabilidad

Eventos Referencias Retención Auditoría

Web3 AdapterOpcional

Proof adjunto Credential verificable Ancla opcional

Regla de integridad

Una respuesta de proveedor no se convierte en evidencia local por el mero hecho de transportarse por la API. Se conserva su referencia, estado y contexto de solicitud. Cualquier prueba criptográfica o mecanismo de.kubernetes-like externalización queda [por validar].

Construido frente a hoja de ruta

Qué está definido y qué debe demostrarse

En esta página, “construido” significa_control, contrato o modelo de evidencia definido en la arquitectura. “Roadmap” significa implementación, integración o validación pendiente. No equivale a disponibilidad productiva.

La paleta de estado es deliberadamente conservadora. Todo estado externo no acreditado permanece [por validar].

Separación entre artefacto de diseño y capacidad operativa
Capacidad	Construido en diseño	Roadmap / gate	Estado verificable
Control de Entitlements	Principio de autorización y contabilización previo a la ejecución. Arquitectura definida	Implementar emisión, validación, consumo, idempotencia, denegación y conciliación con el sistema de cobro.	[por validar] NO MEDIDO
Business API & AI	Contrato conceptual entre intención, validación, autorización y ejecución. Límites definidos	Construir contratos versionados, adaptadores, manejo de errores, trazabilidad y pruebas de seguridad.	[por validar] NO MEDIDO
Open Telco / Open API	Frontera de integración y reglas de mínimo privilegio. Interfaz conceptual	Validar capacidades, credenciales, entornos, contratos, cobertura, límites y tratamiento de fallos por implementación.	[por validar] NO MEDIDO
CAMARA	Modelo para solicitar una señal de red solo cuando el flujo la requiere. Patrón definido	Validar APIs, versión, condiciones de uso, cobertura, proveedor, semántica del resultado y referencia de evidencia.	[por validar] NO MEDIDO
GSMA Open Gateway	Punto de integración para capacidades de red cuando corresponda. Adaptador previsto	Validar elegibilidad, itinerancia, soporte de la capacidad, semántica de errores y evidencia del proveedor.	[por validar] NO MEDIDO
Legal y privacidad	Política versionada como entrada del Control Plane. Modelo configurable	Validar bases de tratamiento, consentimiento, finalidad, retención, derechos, seguridad y地域 aplicable con asesoría competente.	[por validar] NO MEDIDO
Capa web3	Boundary opcional, aislado y descartable. Fuera del núcleo	Definir caso de uso, modelo de amenaza, custody, interoperabilidad, privacidad y economics antes de habilitar cualquier adaptador.	[por validar] NO MEDIDO

El estado por defecto es conservador

La ausencia de evidencia no se interpreta como éxito, disponibilidad ni cumplimiento. Cuando una integración no haya sido probada en el entorno acordado, se informa [por validar]; cuando no exista una medición, se informa NO MEDIDO.

Paquete mínimo de evidencia

Una referencia útil debe poder explicarse sin contexto oculto

El modelo de evidencia se define alrededor de la correlación de una solicitud con sus decisiones, ejecuciones y resultados. La forma exacta del registro, su almacenamiento y su periodo de retención se configuran por política y permanecen [por validar].

Campos que deben resolverse antes del piloto

Identidad de la solicitud request_id o referencia equivalente, generada antes de iniciar una operación.
Decisión de autorización Identificador del Entitlement evaluado, versión de la regla aplicada y resultado de la decisión.
Contexto de política Finalidad declarada, versión de política, jurisdicción aplicable y base de tratamiento cuando corresponda.
Consentimiento consent_reference cuando el flujo afecte datos personales o requiera una base adicional.
Referencia del adaptador Proveedor, capacidad solicitada, identificador de correlación y estado devuelto, sin exponer secretos.
Resultado y retención Resultado normalizado, eventos de ejecución, política de retención y responsable de acceso.

Contrato ilustrativo No es una integración activa

{
  "request_id": "req_reference",
  "entitlement_id": "ent_reference",
  "policy_version": "policy_reference",
  "purpose": "defined_purpose",
  "consent_reference": "consent_reference_or_null",
  "network_signal": {
    "requested": true,
    "provider_reference": "provider_reference"
  },
  "result": "normalized_result",
  "evidence_reference": "evidence_reference",
  "web3_proof": null
}

request_id entitlement_id policy_version consent_reference evidence_reference web3_proof · opcional

Capa web3 opcional

Una extensión puede aportar contexto; nunca sustituye la autorización

La arquitectura no exige wallet, token, cadena de bloques ni mecanismo deexternalización de datos para operar Conecta2. Web3 se incorpora únicamente cuando un caso de uso justificado requiere un proof, una credencial verificable o un ancla de integridad.

Núcleo obligatorio

Control y ejecución

Este camino debe funcionar de manera autónoma y permanecer independiente de la capa opcional.

Business API & AI y Open API.
Open Telco y adaptadores de capacidades.
CAMARA y GSMA Open Gateway cuando la política lo requiera.
Entitlements, cobro, decisión y evidencia.

Adaptador opcional

Web3 como prueba adjuncta

El adaptador puede asociar una referencia externa a una evidencia interna. Laassociation no altera el resultado de una señal de red ni las políticas de acceso.

Proof o referencia verificable, con semántica documentada.
Minimización de datos y modelo de amenaza antes de habilitarlo.
Identidad y custodia que no dependan de una clave compartida con el núcleo.
Retención, acceso y supresión sujetos a la misma política configurable.

No es un sustituto de la evidencia operativa

Un proof externo no demuestra por sí mismo que una señal de red fue obtenida, que una llamada fue ejecutada, que un cobro fue liquidado ni que una política fue satisfied. Esas afirmaciones requieren evidencia del sistema correspondiente.

Gobernanza configurable

Legal y normativo como parte del control, no como texto secundario

Las políticas deben poder revisarse, versionarse y asociarse a cada decisión. Esta página describe el mecanismo de configuración; no ofrece asesoría legal ni declara cumplimiento normativo. Los criterios aplicables a cada jurisdicción y producto están [por validar].

Política de decisión

Regla antes del adaptador

policy_version Identifica la lógica que autorizó, denegó o condicionó la operación.

Versión inmutable una vez registrada.
Ámbito de producto, finalidad y jurisdicción.
Cambio sujeto a revisión y aprobación.

Consentimiento

Referencia, no dato reutilizado

consent_reference Asocia la solicitud a una evidencia de consentimiento cuando la política lo exige.

No se expone el contenido completo en cada registro.
La finalidad se vincula a la operación autorizada.
La revocación y sus efectos se documentan.

Retención y acceso

Minimización verificable

retention_policy Define plazo, propósito y control de acceso para cada clase de evidencia.

Los campos se clasifican antes de la recolección.
El acceso se registra y revisa.
La supresión se propaga a los adaptadores.

La política es un resultado verificable

Cada denegación, condición o revisión debe poder explicar qué regla se aplicó, qué versión estaba vigente y qué evidencia permitió la decisión. Los criterios normativos concretos deben ser validados antes del piloto.

Gates de implementación

Orden recomendado para pasar de diseño a operación

La hoja de ruta es una secuencia de validación. No constituye una promesa de entrega ni un calendario comercial. Cada gate debe producir una evidencia revisable antes de habilitar la siguiente capacidad.

Contrato y modelo de amenaza

Definir el contrato de la Business API& AI, límites de IA, superficies de confianza, datos mínimos y criterios de abortar.

Salida: [por validar]

Entitlements y cobro

Implementar autorización, consumo idempotente, denegación, conciliación y relación entre Entitlements y políticas.

Estado: [por validar]

Adaptadores de red

Conectar Open Telco, Open API, CAMARA y GSMA Open Gateway solo con capacidades y entornos validados.

Cobertura: NO MEDIDO

Web3, si aplica

Evaluar el adaptador opcional fuera del camino crítico. Su inclusión exige justificación, threat model y política propia.

No requerido

Criterio de avance

Una capacidad pasa de modelo a piloto cuando puede responder cinco preguntas

¿Qué autorización explícita permite ejecutarla?
¿Qué política versionada se aplicó?
¿Qué referencia permite correlacionar el resultado?
¿Qué datos se conservan y durante cuánto tiempo?
¿Cómo se revisan los fallos y las denegaciones?

Medición

Indicadores que aún no se declaran

La arquitectura no justifica la publicación de métricas de disponibilidad, latencia, éxito, conversión, fraude, volumen o ahorro. Hasta disposar de un protocolo de medición y una fuente verificable, cada indicador debe mostrarse como NO MEDIDO.

Disponibilidad NO MEDIDO

Éxito de integración NO MEDIDO

Latencia NO MEDIDO

Incidencias NO MEDIDO

Cobertura NO MEDIDO

Satisfacción NO MEDIDO

Identificadores de solicitud, Entitlement y evidencia definidos.
Política de consentimiento y retención revisada.
Errores, reintentos e idempotencia probados.
Adaptadores y proveedores validados por entorno.
Web3 permanece explícitamente fuera del requisito base.
No se publican claims ni métricas sin evidencia.

Siguiente gate

La verificación comienza con un alcance explícito

Una solicitud de piloto debe identificar la capacidad, la política, el adaptador y la evidencia esperados. No presupone integración ni disponibilidad: permite acordar qué debe validarse y con qué criterio de avance.

Solicitar piloto Consultar APIs

Estado de esta página: modelo de arquitectura NO MEDIDO · condiciones, cobertura y disponibilidad [por validar].