Business API & AI · Open Telco

Una capa para activar, verificar y cerrar.

Conecta2 orquesta capacidades de Open Telco, Open API, CAMARA y GSMA Open Gateway en un flujo de producto verificable.

Una interfaz única para que un equipo de negocio active una capacidad de red, la combine con un agente conversacional y conserve evidencia verificable del resultado.

Solicitar piloto Ver APIs
Cobro por Entitlements · Web3 opcional · Estado comercial: por validar
Sesión de negocio EN CURSO
Conecta2 Business API
Orquestación de red y agentes de IA
Flujo de ejemplo Solicitud recibida → Entitlement validado → Señal de red aplicada → Agente en conversación → Cierre registrado.

Qué hace

De la intención al resultado, con control en cada paso

El producto expone una interfaz única para que un equipo de negocio active capacidades de red y automatice una interacción sin perder la trazabilidad de la decisión. Entitlements, consentimientos y evidencias quedan asociados a cada ejecución.

Activa

Solicita y valida el acceso requerido antes de ejecutar una capacidad de red.

Disponibilidad por operador [por validar]

Entiende

Un agente de voz procesa la intención, solicita los datos mínimos y deriva a una persona cuando corresponde.

Modelo de IA y cobertura [por validar]

Cierra

Registra el resultado, conserva la evidencia y ofrece un siguiente paso por el canal autorizado.

Canales de cierre [por validar]

Arquitectura del portafolio

Una frontera de producto estable, construida sobre capacidades modulares

Conecta2.io es la marca del producto. Mobiconnect aparece exclusivamente como endoso. La arquitectura conserva una interfaz única para el cliente y aísla las capacidades de red, los modelos de IA y las políticas operativas detrás de adaptadores intercambiables.

Decisiones de arquitectura

  • Conecta2.io conserva la propiedad de la experiencia, los contratos de producto y la evidencia.
  • Open Telco, Open API, CAMARA y GSMA Open Gateway se integran como capacidades, no como infraestructura expuesta sin control.
  • Los Entitlements gobiernan la autorización y el cobro; las políticas legales y de datos permanecen configurables.
  • La IA es una capacidad orquestable. Web3 es opcional y nunca una condición para completar un flujo principal.

Núcleo de producto

Orquesta el caso de uso, aplica políticas, coordina Entitlements y conserva un identificador de correlación durante todo el flujo.

  • Contratos de entrada y salida versionados.
  • Idempotencia y control de reintentos.
  • Estados verificables y trazabilidad.
Contrato de eventos [por validar]

Capa de red

Encapsula las capacidades disponibles en Open Telco, Open API, CAMARA y GSMA Open Gateway sin trasladarlas directamente al integrador.

  • Adaptadores por capacidad y región.
  • Respuestas normalizadas y estados de error.
  • Disponibilidad sujeta a validación comercial y técnica.
Matriz de cobertura [por validar]

Capa de IA

Adapta reconocimiento de voz, modelos de lenguaje y síntesis para ejecutar la conversación dentro de límites explícitos.

  • Contexto mínimo necesario.
  • Transferencia a persona cuando se configure.
  • Evaluación de calidad pendiente de medición.
Precisión conversacional: NO MEDIDO

Control y cobro

Asocia cada uso autorizado a su Entitlement y conserva la relación entre autorización, ejecución y resultado.

  • Verificación previa del Entitlement.
  • Imputación de consumo según política configurable.
  • Detalle de tarifas y mínimos comerciales [por validar].
Modelo de Entitlements [por validar]

Cómo funciona

Un flujo de seis decisiones auditables

Cada ejecución sigue una secuencia explícita. Si una autorización, una política o una capacidad de red no está disponible, el flujo se detiene o deriva según la política configurada; no se simula una finalización.

Solicitud
Recibe la intención y los datos mínimos.
Entitlement
Valida alcance, vigencia y uso.
Política
Aplica consentimiento y controles.
Orquestación
Ejecuta la capacidad de red o IA.
Conversación
Entiende, responde y deriva.
Evidencia
Registra el resultado y el cierre.

Antes de ejecutar

La API recibe una solicitud con un entitlement_id. Cuando la operación utiliza datos personales, conserva la referencia de consentimiento y la versión de política aplicada. Los campos obligatorios, los límites y los destinos válidos se documentan por capacidad.

  • Validación de esquema y versión.
  • Comprobación del Entitlement y su alcance.
  • Resolución de política por región, canal y caso de uso.
  • Rechazo temprano si falta una autorización necesaria.

Durante la ejecución

El orquestador selecciona el adaptador disponible, propaga un identificador de correlación y conserva estados intermedios. Los tiempos de espera, reintentos y degradaciones deben permanecer dentro de límites definidos por contrato, no por supuestos de interfaz.

  • Reintentos únicamente para errores recuperables.
  • Prevención de solicitudes duplicadas.
  • Respuesta normalizada ante éxito o rechazo.
  • Derivación a humano si la política lo exige.

Después de ejecutar

El sistema conserva una referencia verificable de la decisión: qué capacidad se solicitó, qué política se aplicó, qué estado devolvió la infraestructura y cuál fue el resultado de negocio.

  • Identificador de ejecución.
  • Entitlement y política asociados.
  • Resultado de la capacidad de red.
  • Estado de cierre y siguiente acción.

Cuando no puede completarse

Los rechazos se clasifican para que el integrador pueda distinguir. Un rechazo de política no se presenta como fallo técnico; una degradación de un modelo no se presenta como resultado de red.

  • Autorización: Entitlement ausente, vencido o fuera de alcance.
  • Política: consentimiento, región o canal no permitido.
  • Capacidad: señal o API no disponible.
  • Conversación: ambigüedad, datos sensibles o derivación humana obligatoria.

Maqueta del producto

Una sesión, un resultado y una evidencia verificable

La maqueta representa el estado que un equipo puede consultar durante una ejecución. Los nombres, estados y controles son ilustrativos; no representan una llamada activa ni constituyen una respuesta de una API en producción.

Lectura de la interfaz

  • Sesión de negocio: agrupa la operación relacionada con una intención.
  • Estado: comunica una etapa observable, no una promesa de resultado.
  • Flujo: muestra autorización, política, capacidad, conversación y cierre.
  • Trazabilidad: permite consultar la evidencia asociada sin reconstruirla desde la interfaz.
Maqueta conceptual · sin ejecución real

Eventos mínimos

El contrato de eventos está sujeto a validación técnica. La siguiente estructura describe relaciones, no campos definitivos.

// Modelo conceptual [por validar]
{
  correlation_id: "referencia",
  entitlement_id: "autorización",
  consent_reference: "cuando corresponda",
  capability: "capacidad solicitada",
  policy_version: "versión aplicada",
  status: "estado observable"
}

Gobernanza configurable

La política forma parte del producto, no de una promesa implícita

Las reglas legales, normativas y de datos se configuran por caso de uso, región, canal y versión. El producto registra la política aplicada para que una ejecución pueda explicarse sin depender del estado actual de una configuración.

Dimensiones de control y estado de validación
Dimensión Control configurable Evidencia Estado
Autorización Alcance, vigencia y uso del Entitlement. entitlement_id y decisión de validación. [por validar]
Consentimiento Base, canal, finalidad y versión aceptada. consent_reference cuando corresponda. [por validar]
Datos personales Minimización, acceso, retención y eliminación. Política vinculada al evento. [por validar]
Conversación con IA Información visible, derivación humana y registro de audio. Configuración y eventos de derivación. [por validar]
Canales Destinos permitidos, plantilla y ventana de contacto. Versión de plantilla y resultado de entrega. [por validar]
Web3 Integración opcional y separada del flujo principal. Referencia opcional del adaptador. Opcional

Cifras y disponibilidad

No se publican métricas de disponibilidad, latencia, precisión de voz, tasa de resolución o conversión hasta que exista un método de medición aprobado y evidencia verificable. Estado actual: NO MEDIDO. La cobertura geográfica, de canal y de capacidad permanece [por validar].

Verificable por diseño

La evidencia acompaña cada decisión

La experiencia visual comunica el resultado; el registro verificable permite revisar cómo se produjo. Conecta2 separa el dato presentado al usuario del dato técnico necesario para auditar la ejecución.

Identidad de la ejecución

Un identificador de correlación permite relacionar la solicitud con sus estados y respuestas.

Requisito de diseño

Política aplicada

La versión de política permite reconstruir las reglas vigentes durante la operación.

Requisito de diseño

Resultado de capacidad

La respuesta de la capacidad se normaliza sin ocultar su estado de éxito o rechazo.

Requisito de diseño

Lo que el producto no oculta

  • No declara una capacidad disponible sin una matriz de cobertura validada.
  • No confunde una recomendación de IA con una autorización de negocio.
  • No utiliza Web3 como requisito para una operación de voz o API.
  • No sustituye la evaluación legal del responsable del tratamiento.

Lo que debe validar el piloto

  • Contrato de API y modelo de errores.
  • Matriz de capacidades y regiones.
  • Reglas de consentimiento, retención y derivación.
  • Calidad conversacional y condiciones de operación.
Definir alcance del piloto

Siguiente paso

Conviertamos un caso de uso en un flujo verificable.

Cuente cuál es la interacción, qué señal necesita, qué datos intervienen y qué resultado debe quedar registrado. La disponibilidad se confirmará durante la evaluación técnica.

Solicitar piloto Consultar documentación de APIs