La herramienta que decidimos no construir
Nuestro panel de administración tiene dentro dos cosas que nos importan: los leads comerciales y el blog. Desde hace unas semanas también tiene un asistente conectado, capaz de dar de alta un contacto, apuntar una llamada, mover una oportunidad de etapa o dejar preparado un artículo.
No puede borrar nada. Ni un lead, ni un post, ni una actividad. Y eso no es una funcionalidad que quede pendiente para la próxima versión: es la primera decisión de diseño que tomamos.
Elegir el conjunto de verbos, no el de datos
Conectar un asistente a un sistema propio se hace hoy con un servidor MCP: un proceso que expone un puñado de herramientas —crear, listar, actualizar— y traduce lo que el modelo pide a llamadas contra tu API de siempre.
La tentación es tratar ese servidor como un espejo de la base de datos: si la tabla tiene un DELETE, la herramienta tiene un borrar. Es lo cómodo, y es un error. Un servidor MCP no es una capa de acceso a datos, es una superficie de ataque y de accidente, y su tamaño lo eliges tú, herramienta a herramienta.
Así quedó el nuestro:
- Se crea y se edita. Leads, actividades, posts.
- Se publica y se despublica. Publicar tiene reverso, y el reverso es una herramienta de primera clase, no un truco.
- No se borra. Para eliminar algo hay que abrir el panel y hacerlo con la mano, con el ratón y con la confirmación delante.
El coste de esa decisión es real y lo pagamos nosotros: alguna limpieza se hace a mano. El beneficio también es real, y es que la lista de cosas irreversibles que puede provocar el asistente está vacía.
Los identificadores como control de alcance
Todo lo que hay en el panel se referencia por UUID. No hay lead/1 ni post/12.
Eso empezó siendo una decisión de base de datos y acabó siendo una de seguridad. Un UUID no se puede adivinar ni tantear: el asistente no puede actuar sobre lo que no ha visto antes. Si quiere tocar un lead, primero tiene que listar; y lo que lista es lo que la credencial en uso tiene permitido ver.
Es el mismo principio que un SELECT antes de un UPDATE, solo que aquí no depende de la disciplina de quien escribe la consulta, sino de la forma del identificador.
Vocabularios cerrados
Las etapas del pipeline son seis y están en este orden: nuevo, contactado, reunión, propuesta, ganado, perdido. La herramienta no acepta ninguna otra.
Parece un detalle de validación y es otra cosa: un modelo de lenguaje es una máquina de producir texto plausible, y "en negociación" es plausible. La diferencia entre un embudo que se puede medir y un campo de texto libre con quince variantes de lo mismo es exactamente esa validación.
El texto que escriben terceros
Hay un último detalle, y es el que más nos ha hecho pensar.
El nombre de un lead, sus notas y sus actividades los escriben personas de fuera. Ese texto entra en la conversación del asistente, y si el asistente lo lee como si fueran instrucciones suyas, cualquiera que pueda rellenar un formulario puede darle órdenes.
Por eso el servidor no devuelve ese contenido suelto: lo entrega envuelto en un bloque marcado, con un principio y un final visibles, y con una indicación explícita de que lo que va dentro son datos que hay que leer y nunca instrucciones que haya que obedecer.
No es una barrera criptográfica ni pretende serlo. Es lo mismo que separar el código de los datos: la mitad del trabajo de una defensa es que la frontera se vea.
Por qué lo contamos
Porque describe cómo trabajamos mejor que cualquier adjetivo.
La pregunta que nos hicimos antes de conectar nada no fue "¿qué puede hacer esto por nosotros?", sino "¿qué es lo peor que puede pasar un martes por la tarde?". Con este diseño, lo peor que puede pasar es un borrador de más o un campo mal puesto. Las dos cosas se arreglan en diez segundos y las dos quedan firmadas en la auditoría, a nombre de la credencial que las hizo.
Un sistema no es seguro porque quien lo usa acierte. Es seguro cuando equivocarse sale barato, y eso no se consigue con avisos ni con formación: se consigue no construyendo determinadas herramientas.
