Herramientas internas con IA: cuándo construir y cuándo comprar

Hace dos años, si un área de una empresa quería una herramienta interna a su medida, tenía dos caminos: pedirla al equipo de tecnología y esperar su turno, o contratar un desarrollo externo. Los dos eran caros y lentos. Hoy una persona con criterio y una herramienta de IA para programar puede tener un prototipo funcionando en una tarde.

Eso es una buena noticia, y también una tentación. Cuando construir se vuelve barato, dan ganas de construirlo todo. Yo caí un poco en eso, así que este post es la versión honesta: qué construí para mí, qué no construí, qué me está costando mantener, y los criterios que usaría si tuviera que tomar esta decisión dentro de una empresa con equipo y presupuesto.

Lo que construí

En los últimos meses armé tres herramientas propias, todas con IA y sin tener formación de programador:

• Un CRM. Los contactos del formulario de mi sitio entran solos a una base de datos, las conversaciones por correo quedan agrupadas en cada ficha, y el seguimiento vive en un tablero por estados. Lo conté completo en el post del CRM propio con IA.
• Un panel de métricas. Junta en un solo lugar los datos de Google Analytics, Search Console y Clarity con una medición propia del sitio, mes a mes.
• Una plataforma de operación. Tareas personales, de clientes y de mi marca en un solo calendario, con las reuniones de la semana al lado. La historia está en el post de la plataforma de operación.

Las tres valieron la pena, por una razón común: ninguna herramienta del mercado calzaba con mi flujo sin obligarme a cambiarlo. Mi problema no era falta de software, era que mi información vivía en cuatro lugares y necesitaba verla junta.

Lo que no construí (y no pienso construir)

Esta parte me parece más importante que la anterior, porque es la que casi nadie cuenta.

• El correo. Mi casilla de contacto recibe los mensajes y los reenvía a Gmail, y las respuestas salen por Gmail, incluso las que escribo desde mi panel. Llegué a evaluar montar un envío de correos propio y lo descarté: lo que ya tenía lo resolvía.
• El calendario. Mi plataforma lee mis calendarios de Google, pero no los reemplaza. Las reuniones se siguen creando donde siempre.
• La analítica. Mi panel consulta Google Analytics y Search Console, no intenta ser una alternativa a ellos. Cuando Google no ofrece un dato por su interfaz de programación, lo importo a mano en vez de inventar un atajo frágil.

El patrón es claro: construí la capa que une, no las piezas que ya funcionan. Correo, calendario y analítica son problemas resueltos por empresas que tienen equipos enteros dedicados a eso. Mi ventaja no está ahí.

El costo que no aparece el día que lo construyes

Construir una herramienta con IA hoy es rápido. Mantenerla sigue siendo trabajo, y ese trabajo no se ve en la demo. Algunos ejemplos reales de mis últimos meses:

• Un día los contactos aparecieron en cero. Las tablas del CRM estaban vacías, y hasta hoy no sé la causa. Los recuperé porque la base de datos guarda un historial que permite volver a un punto anterior en el tiempo. Sin eso, los habría perdido.
• Una métrica me mintió sin que me diera cuenta. El panel mostraba muchas visitas de asistentes de IA a mi sitio. Revisando, descubrí que la gran mayoría eran robots que se hacían pasar por esos asistentes para buscar archivos con contraseñas. Lo corregí, y ahora tengo una tarea nueva para siempre: cada vez que agrego una sección al sitio, actualizar la lista de rutas válidas.
• Un error de seguridad de principiante. La primera versión del acceso a mi panel pasaba la clave en la dirección web. Lo corregí el mismo día que lo vi, pero lo vi yo, no un área de seguridad.
• Piezas que se desincronizan. Mi plataforma usa una copia de mi lista de clientes, y cuando esa lista cambia tengo que regenerar la copia a mano. Y todavía tengo pendiente un respaldo automático de las tareas.

Nada de esto es grave para una persona que usa su propia herramienta. En una empresa, cada uno de esos puntos es un incidente: datos de clientes perdidos, decisiones tomadas con una métrica inflada, una clave expuesta.

Cinco criterios para decidir

1. ¿Qué tan específico es tu proceso?

Si tu proceso es el de casi todas las empresas (un embudo de ventas clásico, un flujo de aprobaciones, una mesa de ayuda), compra. Alguien ya diseñó eso mejor que tú y lo mejora todos los meses. Construir tiene sentido cuando tu forma de trabajar es parte de lo que te diferencia, o cuando la herramienta estándar te obliga a trabajar peor para calzar con ella.

2. ¿Cuánto cuesta mantenerla, no construirla?

La IA bajó mucho el costo de construir. El de mantener bajó menos. Antes de aprobar una herramienta interna, pregunta cuántas horas al mes va a necesitar para arreglos, ajustes, respaldos y actualizaciones, y quién las va a poner. Si la respuesta es "nadie en particular", ya sabes cómo termina.

3. ¿Quién la opera cuando el que la hizo no está?

Este es el criterio que más pesa en una empresa y el que menos se pregunta. Una herramienta que solo entiende la persona que la construyó es una herramienta que se cae el día que esa persona se va de vacaciones o cambia de trabajo. Yo lo mitigo documentando cada proyecto en un archivo que explica cómo funciona, cómo se publica y qué está pendiente. Aun así, mi caso es fácil: el que la usa y el que la mantiene somos la misma persona.

4. ¿Qué datos toca y quién responde por ellos?

Una herramienta interna que guarda datos de clientes tiene las mismas obligaciones que cualquier software que lo haga: accesos controlados, respaldos, y cumplimiento de la ley de datos personales, que en Chile se actualizó con la Ley 21.719 (lo expliqué en el post sobre consentimiento y la nueva ley). Un proveedor establecido ya resolvió buena parte de eso. Si construyes, esa responsabilidad es tuya, y en una empresa debería pasar por quien vela por la seguridad antes de ponerse en producción, no después.

5. ¿Qué dejas de hacer mientras la construyes?

El costo de oportunidad es el más fácil de ignorar porque no aparece en ninguna factura. Cada tarde que pasé afinando mi panel fue una tarde que no pasé escribiendo, conversando con clientes o trabajando en lo que me pagan. Valió la pena porque me ordenó la operación, pero no es gratis. En una empresa, la pregunta es si la persona que construye es la más indicada para dedicarle esas horas, o si su tiempo rinde más en su trabajo de siempre.

La tabla de decisión

No hace falta que todas las filas apunten al mismo lado. Pero si la mayoría dice "compra" y aun así quieres construir, conviene que puedas explicar por qué con algo más que "es barato".

Un camino intermedio: construir para aprender qué comprar

Hay un uso de la IA que me parece subestimado en las empresas: construir un prototipo desechable para descubrir qué necesitas. Muchas compras de software salen mal porque nadie sabía bien qué pedir. Un prototipo hecho en una semana, usado por el equipo real durante un mes, te enseña qué funciones importan y cuáles eran ideas bonitas.

Con eso en la mano puedes hacer dos cosas: comprar una herramienta sabiendo exactamente qué exigirle, o decidir que el prototipo ya es suficiente y darle un dueño, documentación y respaldos. Las dos son buenas decisiones. La mala es la tercera, la más común: dejar el prototipo corriendo sin dueño hasta que se cae.

Lo que me llevo

Hace unos meses escribí que la mayoría no necesita un CRM todavía, y después me construí uno. No es una contradicción: el criterio de fondo es el mismo. La herramienta no arregla un proceso que no existe, sea comprada o construida.

Lo que cambió con la IA es el precio de construir, no el precio de equivocarse. Construir se volvió barato; mantener, asegurar y darle continuidad sigue costando lo mismo que antes. La habilidad que vale hoy no es saber construir con IA, es saber qué no construir.

Si en tu empresa están evaluando qué procesos automatizar o qué herramientas armar con IA, esa conversación es justo el punto de partida del trabajo de automatizaciones: primero el proceso, después la herramienta.