IA para personas humanas

Quien trabaja con varias herramientas de IA a la vez se encuentra pronto con un problema poco vistoso: cada una guarda sus proveedores, sus claves, sus conectores y sus instrucciones en un sitio distinto.

Claude Desktop tiene su configuración. Codex tiene la suya. Gemini CLI, OpenCode, OpenClaw o cualquier herramienta parecida también. Al principio no molesta. Cuando empiezas a usar varios proveedores de modelos, varios MCPs y varias skills, el mantenimiento deja de ser una molestia pequeña y se convierte en una fuente real de errores.

El problema de fondo no es tener muchas herramientas. Es no tener una capa común para gobernarlas.

Qué se está intentando centralizar

Hay tres piezas que conviene separar de la herramienta concreta que estés usando ese día.

Proveedores de modelos. OpenAI, Anthropic, Google, proveedores locales, relays, cuentas corporativas, cuentas de prueba. Si cada herramienta tiene su propia lista, cualquier cambio de clave, endpoint o modelo obliga a repetir trabajo.

MCPs. Un MCP es un conector que permite a un agente usar herramientas externas: leer archivos, consultar una base de datos, operar con una API, buscar en un repositorio. Lo razonable es no instalar el mismo conector cuatro veces si varias herramientas pueden apuntar a una configuración común.

Skills e instrucciones. Una skill es una capacidad empaquetada: instrucciones, criterios y a veces scripts para que el agente haga una tarea de forma consistente. Si una empresa empieza a definir buenas skills internas, duplicarlas manualmente en cada herramienta es una forma bastante rápida de perder control de versiones.

La idea útil es sencilla: una carpeta o base de configuración central, y después enlaces o copias controladas hacia cada herramienta. En Windows eso suele significar enlaces directos o symlinks; en macOS y Linux, enlaces simbólicos. Lo importante no es el mecanismo concreto, sino dejar de mantener cinco versiones de lo mismo.

CC Switch como señal de hacia dónde va el mercado

CC Switch es interesante porque empaqueta varias piezas que hasta ahora mucha gente resolvía a mano. Según su documentación pública, gestiona desde una sola aplicación herramientas como Claude Code, Claude Desktop, Codex, Gemini CLI, OpenCode, OpenClaw y Hermes. También incorpora gestión unificada de MCPs y skills, presets de proveedores, proxy local, failover, seguimiento de uso y sincronización entre equipos.

La parte relevante no es que sea "la herramienta definitiva". Ese tipo de herramienta envejece mal. Lo relevante es que reconoce una necesidad real: las herramientas de agentes están creciendo más rápido que la capacidad de gestionarlas una a una.

En la práctica, una capa así sirve para tres cosas.

Primero, cambiar de proveedor sin tocar archivos de configuración a mano. Si una cuenta llega a su límite, si un proveedor falla o si necesitas comparar calidad entre modelos, el cambio puede hacerse desde un punto central.

Segundo, mantener MCPs y skills de forma más ordenada. CC Switch detecta configuraciones existentes, permite instalar nuevas piezas y puede usar una carpeta común con enlaces o copias hacia las herramientas compatibles. Esto no elimina la necesidad de criterio, pero reduce el trabajo repetitivo.

Tercero, ver qué se está usando. Un proxy puede registrar peticiones, proveedores, modelos y gasto. Para una persona sola quizá sea comodidad. Para un equipo, empieza a ser gobierno básico.

El proxy no es solo comodidad

Un proxy de modelos es una capa intermedia entre tus herramientas de IA y los proveedores que responden. En vez de que cada herramienta hable directamente con cada API, todas pasan por un punto común.

Eso permite cosas útiles: failover si un proveedor falla, cambio rápido entre modelos, rectificación de peticiones con formatos incompatibles, estadísticas de uso y, en algunos casos, reglas para repartir carga entre cuentas o proveedores ahorrando tokens.

Pero también añade una capa más. Y cada capa nueva tiene coste: latencia, mantenimiento, seguridad y dependencia de otra pieza que debe estar arrancada para que todo funcione. CC Switch, por ejemplo, levanta un servicio local para actuar como proxy; por eso incorpora un modo ligero que cierra la interfaz gráfica y deja el servicio funcionando con el menor consumo que le es posible.

La decisión sensata no es "poner un proxy porque se puede". Es ponerlo cuando resuelve un problema real: varios proveedores, varias herramientas, necesidad de failover, control de gasto o trazabilidad. Si solo usas una herramienta con una cuenta estable, quizá no necesitas nada más.

Cuidado con los free tiers

Los free tiers de proveedores de IA son útiles para experimentar: comparar calidad, medir rendimiento, probar flujos o validar si un modelo encaja con una tarea concreta.

El problema empieza cuando se usan como si fueran infraestructura de empresa.

Muchos planes gratuitos o de prueba permiten acceder a modelos recientes a cambio de condiciones menos estrictas sobre el uso de datos. En algunos casos, el proveedor puede usar las entradas para mejorar sus modelos. Eso no significa que todo free tier sea peligroso por defecto, pero sí que no se debe usar con información confidencial sin leer condiciones, política de datos y opciones de privacidad.

La regla práctica es simple: datos privados, clientes, estrategia, finanzas, código sensible o documentación interna no deben pasar por un proveedor de prueba sin validación previa. Si hace falta probar, se anonimizan y "censuran" los datos antes (tipo documento con tachones de la CIA en las pelis), se trabaja con un modelo local o una cuenta corporativa con garantías suficientes.

Ahorrar unos euros en tokens no compensa una fuga de información.

Qué significa esto para una empresa

El patrón que empieza a aparecer es más importante que la herramienta concreta.

Durante la primera fase de adopción de IA, cada persona prueba su herramienta favorita. En la segunda fase, el equipo necesita compartir método. En la tercera, la empresa necesita gobernar configuración, permisos, proveedores, costes y conocimiento reutilizable.

Centralizar providers, MCPs y skills forma parte de esa tercera fase. No sustituye a una política de seguridad ni a una buena arquitectura, pero evita que cada herramienta sea una isla. Y cuando las herramientas dejan de ser islas, se puede empezar a hablar de estándares internos: qué proveedores están permitidos, qué MCPs se instalan, qué skills son oficiales, qué datos pueden salir y qué métricas se revisan.

La pregunta útil no es si CC Switch, LiteLLM, Olla u otra herramienta será la ganadora. La pregunta es si tu organización tiene claro dónde vive la configuración común de sus agentes de IA. Si la respuesta es "en cada portátil y como cada persona pudo", todavía no hay sistema. Hay uso individual más o menos avanzado.