La IA cambia cada trimestre. Tus conexiones no deberían.

Un martes, un equipo pasa de ChatGPT a Claude. La suscripción tarda treinta segundos. La configuración tarda tres semanas.

No porque Claude sea difícil. Porque once apps estaban conectadas dentro de ChatGPT, cada una con su propio grant OAuth, sus propios scopes, su pedacito de memoria institucional. El nuevo asistente empieza sin nada de eso. Alguien reautoriza Gmail, Slack, Notion, Stripe y la base de datos interna. Alguien descubre que el asistente anterior tenía un scope de calendario más amplio de lo que el nuevo permite. Alguien pregunta por qué la pista de auditoría tiene un hueco el día del cambio, y nadie tiene una buena respuesta.

La factura del modelo es visible. La factura del cambio no lo es, y suele ser mayor.

Yo fundé Vinkius, y este es el patrón que veo en casi todos los equipos que usan IA en serio. El asistente se trata como el lugar donde ocurre el trabajo, así que las conexiones se construyen allí. Pero el asistente es la capa menos duradera de la pila. Los modelos cambian cada trimestre. Los clientes cambian su modelo de conector, su pantalla de ajustes, su precio. Las apps que conectas son la parte estable. La relación entre tu gente y esas apps es el activo.

El error es arquitectónico, no táctico. Estandarizamos la llamada a herramientas con MCP y luego dejamos que cada cliente fuera dueño de la conexión que la produce. El resultado es una capa de conexión duplicada por asistente, por usuario, por dispositivo, e imposible de auditar como un solo sistema.

Cambiar de IA debería ser un pegado, no una migración.

La factura que no ves

Cada cambio tiene un costo visible y uno oculto. El visible es la suscripción, el número de asientos, el correo de migración. El oculto es el trabajo de reconstruir la relación entre tu equipo y sus apps, una pantalla de consentimiento a la vez.

Lo que realmente cuesta un cambio	Qué pasa	Por qué se acumula
Reautenticación	Cada app pide consentimiento otra vez, por cliente	Cada grant crea un token nuevo, con su propia expiración y su propio scope
Deriva de permisos	El nuevo cliente expone un modelo de permisos distinto	La política vive en la interfaz, así que se recrea a mano
Discontinuidad de auditoría	Los logs se quedan con el proveedor anterior	No hay una línea de tiempo única que cruce el cambio
Reconstrucción de integraciones	Cada cliente tiene su propio formato de conector	El trabajo se repite para cada app y cada cliente
Confusión de identidad	Las cuentas personales y de trabajo se mezclan	La cuenta equivocada puede actuar con la intención correcta
Pérdida de contexto	Prompts, favoritos y rutinas se quedan atrás	El asistente olvida cómo trabaja tu equipo

Nada de esto aparece en un benchmark. Todo esto aparece el primer mes.

Tres capas de lock-in

El lock-in de modelo es el que todo el mundo discute. Es real, pero tiene precio. Puedes medirlo, negociarlo, desviarlo con un segundo proveedor, y el mercado sigue empujando el precio hacia abajo.

El lock-in de cliente es el que todo el mundo siente. Es el hábito, el atajo de teclado, la convención del equipo, el proyecto que ya vive en una barra lateral. También es real, pero es sobre todo un problema de UX, y los problemas de UX suelen resolverse en la siguiente versión.

El lock-in de conexión es el que nadie nombra. Es el costo de reconstruir la relación entre tu gente y sus apps cada vez que cambia la interfaz. No aparece en un contrato. Aparece como tres semanas de configuración y un hueco en la pista de auditoría.

Dibuja la matriz. Cinco asistentes en las columnas, doce apps en las filas. Sesenta celdas. Cada celda necesita un flujo de autenticación, una credencial, un scope, una política y una línea de log. Ahora añade un segundo usuario, un segundo dispositivo, un segundo framework de agentes. La matriz se multiplica, y cada celda la mantiene alguien que no la construyó.

Una capa de conectividad colapsa la matriz. Las apps se conectan una vez. Cada cliente recibe un enlace. La política y el registro viven en la capa, no en la celda.

Qué se rompe cuando la conexión vive dentro del cliente

La credencial hereda la postura de seguridad del cliente. La forma más rápida de conectar una app a un asistente es pegar un token en su configuración. Ahora el token está en el almacenamiento del cliente, en sus logs, bajo su política de retención, y en la ventana de contexto de un modelo que no controlas. Una conexión que vive en el cliente hereda la postura de seguridad del cliente, que no es una frase que ningún equipo de seguridad quiera firmar.

El modelo de permisos se recrea a mano. Cada cliente tiene su propia idea de lo que un conector puede hacer. Un permiso que existe en un asistente puede no existir en el siguiente, y la política cuidadosamente definida el lunes se reconstruye de memoria el miércoles. La deriva es invisible hasta que una acción que debería haber sido bloqueada sale bien.

La pista de auditoría se parte en el cambio. Cuando la llamada la hace el cliente, el registro lo hace el cliente. Cambia de cliente y la línea de tiempo se divide en dos. La pregunta después de un incidente no es "qué dijo el modelo", sino "quién autorizó esta acción, para qué cuenta, a qué hora". Un log por cliente no responde eso entre clientes.

El mantenimiento nunca termina. Cada cliente lanza un formato nuevo de conector, una pantalla nueva de ajustes, un JSON nuevo. Cada app cambia su API, sus scopes, su flujo OAuth. El trabajo de integración no desaparece cuando pasas a un conector gestionado. Pasa a quien mantiene el conector, y si esa persona eres tú, vuelve cada trimestre.

La identidad se comparte. Un enlace pegado en un canal del equipo es una identidad compartida. Un token commiteado en un repositorio es una identidad compartida. Una conexión que debía pertenecer a una persona ahora pertenece a todos los que pueden leer el canal. La conexión debe estar atada a una persona, no a una ventana de chat.

La portabilidad es arquitectura, no un botón de exportar

La palabra portabilidad suele significar un botón que exporta tus datos. Eso no basta. Un CSV de tus conexiones no las reautentica, no lleva permisos, no preserva la pista de auditoría y no hace funcionar al siguiente cliente. La portabilidad es una propiedad del camino, no de un archivo.

Una conexión es portátil cuando cumple ocho requisitos:

Requisito	Qué significa en la práctica
Endpoint estable	Una URL por usuario que no cambia cuando cambia el cliente
Atado a la identidad	El endpoint lleva a la persona, no a la ventana de chat ni al dispositivo
Protocolo abierto	La frontera habla MCP, así que cualquier cliente compatible se conecta
Credenciales externas	Los secretos viven en una bóveda, nunca en el cliente ni en el contexto del modelo
Política externa	La autorización se evalúa por acción, fuera de la interfaz del cliente
Auditoría externa	Cada llamada se registra en la capa, en una sola línea de tiempo
Token revocable	El enlace se puede revocar y reemitir sin reconstruir las apps
Las mismas capacidades en todas partes	Chat, IDE, terminal y tus propios agentes ven el mismo catálogo

Si una conexión muere cuando se desinstala el cliente, nunca fue tuya.

Cómo lo hace un solo enlace

La unidad es un enlace de Connector, una URL con la forma https://edge.vinkius.com/vk_YOUR_TOKEN/mcp. Lleva tu identidad a la capa. Lo pegas en ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, DeepSeek, Cursor, VS Code, Windsurf, JetBrains, Claude Code, Cline, Lovable, Antigravity, OpenClaw/ClawX, Goose, Claude Desktop o cualquier cliente compatible con MCP. Para los agentes que construyes, las mismas capacidades llegan por el AI Connect SDK, con adaptadores para Vercel AI SDK, OpenAI Agents, Anthropic, Google ADK, LangChain, CrewAI, Semantic Kernel y AutoGen.

Un enlace, una identidad, todos los clientes.

El catálogo es just-in-time. El modelo no necesita aprenderse 9.268 nombres de Connectors. Busca por la tarea, inspecciona las capacidades, conecta y ejecuta. Hoy el catálogo lleva 9.268 Connectors gestionados y 63.133 capacidades, y el número se mueve a medida que el catálogo se sincroniza.

Las credenciales de las apps no están en el cliente. Están cifradas en reposo y nunca vuelven al modelo. La política se evalúa por acción. La pista de auditoría se escribe en la capa, así que sobrevive al cambio. El enlace es un bearer token: trátalo como una llave, mantenlo fuera de los repositorios y revócalo en la consola si se filtra. Un token nuevo se emite en segundos, y el anterior deja de funcionar.

El mismo enlace funciona en un IDE o en un cliente de escritorio. Claude Desktop lo lee de su archivo de configuración:

{
  "mcpServers": {
    "vinkius-ai-connections": {
      "url": "https://edge.vinkius.com/vk_YOUR_TOKEN/mcp"
    }
  }
}

El cliente cambia. La configuración cambia. El enlace no.

Una migración para ejecutar esta semana

Inventaría las conexiones. Lista las apps, el dueño de cada cuenta, los scopes en uso y la última vez que se llamó a cada una. No empieces por las apps fáciles. Empieza por las que dolerían si estuvieran conectadas a la cuenta equivocada.

Conecta una vez en la capa. Autoriza cada app una vez, en un solo lugar. El trabajo es por app, no por app por cliente. Es toda la diferencia entre una matriz y una lista.

Pega el enlace en un segundo cliente y ejecuta tres tareas reales. Una lectura, una escritura y una que debería bloquearse. La tercera prueba es la importante. La portabilidad sin un "no" es solo comodidad.

Mueve la política a la capa. Aprobación por acción para operaciones destructivas, patrones de prevención de pérdida de datos para PII y campos financieros, un techo de gasto y un interruptor que detiene a todos los agentes. La política aplica a todos los clientes a la vez porque no vive en ninguno de ellos.

Retira los tokens antiguos por cliente. La migración no termina cuando funciona el cliente nuevo. Termina cuando se cierra el camino antiguo. Revoca los tokens que se pegaron en las configuraciones de los clientes y comprueba que nada dependa todavía de ellos.

Documenta el dueño y la rotación. Un bearer token sin dueño es un incidente esperando una fecha. Pon el enlace bajo la misma disciplina que cualquier otro secreto de producción.

La objeción del lock-in

Toda conversación de arquitectura acaba en esta pregunta: ¿no estás simplemente cambiando un lock-in por otro?

Es una pregunta justa, y la respuesta es una distinción. Lock-in por rehén significa que irte te cuesta la capacidad de trabajar. Lock-in por valor significa que irte te cuesta un producto mejor, pero todavía puedes trabajar. El primero es una trampa. El segundo es una elección.

Una capa de conectividad debe hacer la salida barata a propósito. El protocolo es abierto. El enlace es tuyo. El token se puede revocar y reemitir. Las conexiones no se guardan en un cliente que puede descontinuarlas. Si la capa desapareciera mañana, perderías comodidad, no tus apps ni tus cuentas. Esa es la vara con la que quiero que me midan.

La portabilidad no es una función que se añade al final. Es la razón de que la capa exista.

La seguridad es el requisito previo

Un enlace que alcanza todas las apps es una llave maestra, y una llave maestra sin control es peor que diez tokens dispersos. Portabilidad y gobernanza son el mismo diseño: ambas exigen que la conexión viva en un camino que controlas.

Los controles no son extras opcionales. Son lo que hace seguro llevar el enlace:

• Autorización por acción, evaluada antes de que salga la llamada, en lugar de un scope amplio de token.
• Aislamiento de credenciales, con secretos cifrados en reposo, autenticados con firma y nunca colocados en el camino del modelo.
• Patrones de prevención de pérdida de datos comparados en memoria antes de que la respuesta llegue al modelo.
• Una pista de auditoría a prueba de manipulación, donde cada registro se encadena al anterior y se firma.
• Techos de gasto y un circuit breaker que detiene un bucle antes que la factura.
• Un interruptor de emergencia que desactiva todos los Connectors, revoca todos los tokens y termina todas las sesiones.

Como los controles viven en la capa, aplican a todos los clientes a la vez. Es el segundo beneficio de la portabilidad: corriges una política una vez, y se mantiene en ChatGPT, Claude, Cursor y el agente que despliegues el mes que viene.

El argumento más largo para cada control está en El plano de control de la era de los agentes y Gobernanza de IA.

Preguntas frecuentes

¿Cambiar de cliente pierde mi historial de chat? El historial de chat pertenece al cliente y se queda allí. Lo que te acompaña es la conexión: las apps, las credenciales, los permisos y el registro de ejecución. Son activos distintos, y solo uno de ellos debería estar atado al asistente.

¿Todos los clientes de IA soportan esto? Cualquier cliente compatible con MCP puede pegar el enlace. Hoy se cubren más de 20 clientes, incluidos los principales apps de chat, IDEs y agentes de código. Para clientes sin MCP, o para tus propios agentes, el AI Connect SDK expone las mismas capacidades mediante adaptadores de framework.

¿Un solo enlace es seguro? Es un bearer token, así que es tan seguro como su manejo. Mantenlo fuera del control de versiones, atado a una identidad, revócalo si se filtra y rótalo con un calendario. La capa aplica política por acción incluso cuando el enlace es válido, así que un enlace filtrado no significa automáticamente manos libres.

¿Dos clientes pueden usar el mismo enlace al mismo tiempo? Sí. Cada llamada se atribuye a la misma identidad y se registra en la misma pista. Si necesitas identidades separadas, emite enlaces separados.

¿Y mis propios agentes? El mismo catálogo está disponible a través del SDK, con conectores y credenciales por usuario. El runtime del modelo cambia; la conexión no.

¿Esto es solo para MCP? MCP es la frontera que estandarizamos porque es el enchufe más amplio. La capa en sí es agnóstica al protocolo, y los adaptadores del SDK cubren frameworks que no hablan MCP directamente.

El asistente es una pestaña

El asistente es una pestaña. El modelo es un número de versión. La conexión es el trabajo.

Los modelos seguirán cambiando. Los clientes seguirán lanzando pantallas nuevas de ajustes. Las apps sobre las que trabaja tu equipo seguirán siendo más o menos las mismas, y la relación entre tu gente y esas apps no debería reconstruirse cada vez que lo hace la interfaz.

Configúralo una vez. Pega el mismo enlace en la próxima IA que uses. Cambia de IA. Mantén las conexiones.