Por qué volcar datos desorganizados no resuelve nada
Si tu CRM o tu base de correos están desorganizados, la IA no lo arreglará por ti. Lo digo de forma directa: usar estas herramientas sobre datos desordenados «va a multiplicar la mierda que ya tienes desorganizada». La frase es cruda, pero resume bien el razonamiento.
El punto de partida está en la fuente de datos. Antes de pedir a un modelo que cruce información, analice ventas o prepare un informe, necesito saber que los datos están limpios y organizados. Lo describí como condición para los paneles internos que uso hoy en la empresa: puedo montar un informe con un prompt, pero la dificultad real está en saber qué quiero y asegurar que las fuentes de datos estén organizadas antes de reunirlas en una tabla.
Aísla cada proyecto como un contexto propio
En el nivel que llamé «integrador», el cuarto de los siete niveles que uso como referencia, la persona ya no trata todas las conversaciones con la IA del mismo modo. Empieza a crear proyectos separados, cada uno con instrucciones y archivos propios, casi como una isla de información.
Esto ocurre, por ejemplo, al crear asistentes personales en ChatGPT con contexto propio, proyectos en Claude con instrucciones y archivos dedicados, o mediante NotebookLM.
La lógica es sencilla: cada proyecto tiene una necesidad distinta y un tipo de información diferente. Mezclarlo todo en una conversación genérica diluye el contexto y obliga al modelo a adivinar qué es relevante. Separar por objetivo permite que cada proyecto «pueda evolucionar con el tiempo y mejorarse a sí mismo».
Si estás organizando procesos comerciales separados de los de entrega, conviene mantener aislados los repositorios de cada área, sin mezclar los historiales de clientes con las reglas internas de operación.
Qué contexto doy a un asistente de IA antes de analizar una cuenta de anuncios
Qué necesita saber un asistente de IA sobre tu negocio
Instrucciones permanentes frente a datos de la sesión
Una diferencia que marqué entre niveles de madurez es saber qué queda fijo en las instrucciones de un proyecto y qué es solo un dato del momento. Las reglas que no cambian, como el tono de voz de la empresa con los clientes, pueden guardarse en las instrucciones permanentes de un asistente o proyecto.
Lo que cambia en cada tarea, ya sea un archivo, un extracto o un texto específico, es lo que entra en la conversación ese día.
Esta separación evita repetir siempre las mismas reglas y permite al modelo mantener la coherencia entre tareas. Puedes empezar por identificar en tu propio flujo qué nunca cambia en la operación y aislarlo en una configuración permanente, dejando la ventana de trabajo libre para los datos variables.
Seguridad: las precauciones que tomé antes de lanzar un bot público
Conté un ejemplo concreto: antes de lanzar públicamente un bot en WhatsApp, mi equipo y yo probamos exhaustivamente intentos de prompt injection, porque accedía a archivos internos. Aun así, en las primeras diez interacciones, cuatro o cinco personas intentaron engañarlo para que revelara instrucciones de base y datos empresariales.
Subrayé que «nunca ha habido un momento tan bueno para ser hacker», precisamente porque muchas personas publican cosas en internet sin cuidado, creyendo que un enlace «oculto» está protegido. No lo está. En un proyecto de vibe coding, lo que más tiempo consume es asegurar la seguridad después de construir, pasando el proyecto por revisiones y distintos modelos hasta alcanzar un nivel de confianza más alto antes de publicarlo, mientras que montar el panel puede llevar solo media hora.
Si vas a dar a un modelo acceso a archivos o datos sensibles, conviene probar deliberadamente si resiste solicitudes manipuladas antes de exponerlo a cualquier persona.
De los chats reactivos a las herramientas que construyes tú
El nivel más avanzado que describí consiste en construir tus propias herramientas sobre IA. Di ejemplos concretos: un panel de aprobación creativa con clientes que sustituyó el Excel desorganizado del equipo y correos automáticos personalizados mediante Resend y Claude Code para una porra con unos 80 participantes.
En ese ejemplo, pido mediante un prompt que el sistema envíe un correo personalizado a cada participante según lo que rellenó o hizo en la aplicación, sin organizar etiquetas manualmente como haría en un CRM tradicional como Active Campaign. Mi intención entonces era dejar de usarlo porque pagaba por un conjunto de funciones de las que solo aprovechaba una parte.
La idea central es que antes las empresas tenían que adaptarse a las herramientas disponibles en el mercado; hoy, para quien sabe construir, el proceso se invierte: se construye la herramienta a medida de la necesidad, en lugar de adaptar el negocio a la herramienta.
Qué cambia esto en el trabajo diario
El hilo conductor de estos ejemplos es la disciplina previa: datos limpios, contexto aislado, reglas separadas y seguridad probada antes de publicar. Subrayé que nadie necesita avanzar despacio nivel por nivel. Vi alumnos presenciales empezar desde lo más básico y construir sus propios sistemas operativos en solo dos días.
El reto consiste en superar la creencia de que esto no es para ti. Quien entiende cómo organizar contexto y datos antes de pedir a la IA que trabaje con ellos ya ha recorrido buena parte del camino para aprovecharla en serio.
El caso de Resend: cuando construir sustituye a suscribirse
Quiero desarrollar un poco más el ejemplo concreto de la porra del Mundial, porque ilustra la diferencia entre pagar una herramienta completa y construir solo la parte que necesito. En Active Campaign, para enviar un correo personalizado a cada participante, tendría que organizar etiquetas, crear automatizaciones condicionales y mantenerlo todo actualizado manualmente conforme avanza la competición. Eso es trabajo recurrente de configuración, además del costo de la suscripción.
Con Resend integrado mediante Claude Code, el proceso hipotético sería diferente. Daría una instrucción en lenguaje natural, por ejemplo, comprobar quién aún no ha enviado sus pronósticos para los próximos partidos, calcular la posición de cada persona en la clasificación y generar un correo con esos datos específicos para cada participante. El sistema no necesita etiquetas preconfiguradas porque recoge la información directamente de la aplicación en el momento del envío.
La diferencia práctica es que la personalización deja de depender de una estructura preparada previamente y pasa a depender de la calidad de la instrucción dada en ese momento. Esto solo funciona, como ya dije en otra sección, si los datos de origen están organizados. Si la aplicación de la porra tuviera resultados mal registrados o campos incoherentes, pedir al sistema correos personalizados multiplicaría los errores, en lugar de simplificar el trabajo.
Conviene recordar que esta solución se pensó para una necesidad interna específica con unos 80 participantes, no como sustituto genérico de un CRM completo. Si alguien tiene una base de miles de contactos con necesidades de segmentación mucho más complejas, compararla directamente con una herramienta como Active Campaign exigiría más cautela antes de decidir una migración.