Lo que la gente pregunta antes de escribirnos

Es software que hace un trabajo repetitivo que hoy tu equipo hace a mano, donde parte de ese trabajo implica leer o juzgar algo. La automatización común mueve datos entre sistemas siguiendo reglas fijas. La automatización con IA se encarga de los pasos donde la regla es difícil de escribir: clasificar un mensaje según de qué se trata, sacar cifras de un documento sin formato consistente, o responder una pregunta a partir de un cuerpo de conocimiento. Las dos suelen combinarse en un mismo sistema.

Sobre todo en que arranca donde se detiene la automatización por reglas. Si tus herramientas actuales se rompen cada vez que llega un documento con un formato inesperado, o necesitan que una persona lea algo antes de que corra el siguiente paso, ahí está la frontera. El trabajo suele ser menos reemplazar lo que tienes y más quitar el paso manual que quedó en la mitad.

Muchas veces solo mejor automatización, y ese es un hallazgo normal. Un modelo de lenguaje es caro y no determinista, así que es la herramienta equivocada para un paso que una regla resuelve de forma confiable. La pregunta útil es cuáles pasos de tu proceso necesitan criterio de verdad, y esos suelen ser una minoría.

Tres cosas: se repite con una frecuencia fija, consume horas que alguien podría contar, y un error en él cuesta algo. Un proceso que corre dos veces al año es mal candidato por tedioso que sea. Si quieres un número antes de hablar con nadie, la calculadora de retorno de este sitio estima el costo anual de una tarea repetitiva a partir de cuatro datos.

Entonces ese suele ser el primer proyecto, y es mejor descubrirlo en el diagnóstico que a mitad de camino construyendo encima. Un sistema de recuperación construido sobre datos que se contradicen produce respuestas seguras y equivocadas, y la falla parece un problema de IA cuando no lo es.

Yo. Datasmarts es una sola persona, Jesús Martínez, y la persona con la que hablas en la primera llamada es la que escribe el código. No hay una capa de ejecutivos de cuenta ni una entrega a un equipo que no conoces. La contrapartida es la capacidad: tomo pocos proyectos a la vez, así que los tiempos son reales y no optimistas.

Con una conversación sobre tus procesos, no con una especificación. Recorremos qué corre a mano hoy, con qué frecuencia y más o menos qué consume, y eso produce una lista corta priorizada con un costo asociado a cada candidato. La construcción, si la hay, se cotiza desde esa lista y no desde una lista de deseos.

Acceso a las personas que ejecutan el proceso, más que acceso a la documentación. Las correcciones manuales que nadie escribió suelen ser los requisitos reales, y la única forma de encontrarlas es ver el trabajo mientras ocurre. Fuera de eso, acceso de lectura a los sistemas involucrados y una persona que pueda decidir.

Depende del proceso, y el diagnóstico es lo que vuelve honesta esa respuesta en vez de una adivinanza. A lo que sí me puedo comprometer es a la forma: la versión automatizada corre junto a la manual hasta que los resultados coinciden, así que el cambio ocurre cuando está la evidencia y no cuando termina la construcción.

Corre en tu infraestructura y tus cuentas, y lo puedes mantener. Los flujos que alguien sin perfil técnico debería poder leer se quedan legibles, las partes que en realidad son software quedan documentadas y probadas, y te entrego lo que construí. Llevar el mantenimiento adentro es un desenlace normal y no un problema.

En dos etapas. El diagnóstico se cobra por separado y produce una lista corta priorizada con un costo asociado a cada proceso candidato. Si después viene una construcción, se cotiza con alcance fijo a partir de esa lista, así que apruebas un trabajo específico a un precio conocido en vez de abrir un contador por hora. Escríbeme con el proceso que tienes en mente y recibes un número para el diagnóstico.

Porque es el entregable, no una llamada de ventas. Implica recorrer tus procesos con las personas que los ejecutan, ponerle horas y dinero a cada uno, y escribir qué hacer primero y qué dejar quieto. Una versión gratis de eso es una propuesta con la conclusión ya decidida, que es justo aquello a lo que esto pretende ser una alternativa.

Entonces lo dice, y de todas formas te quedas con aquello por lo que pagaste. Algunos procesos corren tan poco que no justifican el trabajo, algunos están por cambiar y se automatizarían dos veces, y algunos salen más baratos si les quitas un paso que si lo automatizas. Saber cuál de esos tienes vale más que una construcción que nadie usa.

A veces, si ya sabes cuál proceso es y puedes mostrar lo que cuesta hoy. Lo que no se puede saltar es la línea base: sin un número de partida registrado no hay forma de decir después si la cosa funcionó, y medir el resultado es la mitad de lo que estás pagando.

No. Lo que se construye corre en tu infraestructura y tus cuentas, y la entrega incluye documentación de qué hace y cómo cambiarlo. No hay un esquema de hosting, ni licencia por usuario, ni un componente que deje de funcionar si dejas de hablar conmigo.

A infraestructura que tú controlas, por defecto. Los procesos leen desde los sistemas donde ya viven tus datos y escriben los resultados de vuelta en un almacén en tus cuentas. Cuando hay un modelo de lenguaje de por medio, el texto relevante se envía a ese proveedor mientras dura la llamada, y cuál proveedor es se vuelve una decisión explícita en lugar de un supuesto.

Muchas veces sí, y vale la pena preguntarlo temprano porque le da forma al diseño. Los modelos de pesos abiertos autoalojados son una opción real para clasificar y extraer, y la contrapartida suele ser costo y precisión, no viabilidad. Cuando el paso sensible se puede separar del resto, un patrón común es dejar ese paso local y rutear hacia afuera solo el trabajo no sensible.

Python para las partes que en realidad son software, n8n autoalojado para la orquestación que alguien sin perfil técnico debería poder leer, y el modelo de lenguaje que le quede a cada paso. La elección del modelo es una decisión de diseño que se revisa, no un compromiso con un proveedor, y los sistemas se construyen para que un modelo se pueda cambiar sin reescribirlos.

Tú. El código, los flujos y la documentación son tuyos al momento de la entrega, y corren en tus cuentas. Nada se te licencia de vuelta y nada depende de que siga existiendo una cuenta de Datasmarts.

En parte, y la división es deliberada. Los flujos que alguien sin perfil técnico debería poder leer y ajustar se construyen para quedarse así en la capa de orquestación. Todo lo que haga procesamiento de lenguaje en varias etapas, normalización de APIs o manejo de estado se escribe como Python probado, porque dejarle eso a alguien sin perfil técnico no le hace un favor a nadie.