---
title: "Climatización Norte: descubrir una oportunidad y diseñar la primera prueba"
description: Cómo Idoneos trabaja con Climatización Norte para descubrir
oportunidades de mejora, estimar costos y diseñar una prueba de concepto con
IA.
author:
name: Walter Jerusalinsky
title: Estrategia e implementación de IA
url: https://www.linkedin.com/in/walter-jerusalinsky/
canonical: https://www.idoneos.com/ai-use-cases/climatizacion-norte-memoria-obras-ia/
image: resources/memoria-compartida.png
source: ai-use-cases/climatizacion-norte-memoria-obras-ia/index.md
---
# Climatización Norte: descubrir una oportunidad y diseñar la primera prueba
En una jornada relatada por Federico, dueño y CEO de Climatización Norte, había recibido 130 consultas de arquitectos e instaladores. A las 23 había resuelto aproximadamente la mitad. La escena permite reconocer una dificultad: una parte importante del trabajo necesita pasar por una persona que reúne el conocimiento y el criterio para decidir.
¿Qué parte de ese esfuerzo exige su intervención y qué parte consiste en buscar, reunir o volver a explicar algo que ya se sabe? Esa pregunta organiza el trabajo que estamos definiendo con la empresa. Nos interesa mostrar el recorrido: observar una dificultad, descubrir una oportunidad de mejora, estimar qué costaría realizarla y diseñar una prueba que permita comprobar su utilidad.
La propuesta es construir una memoria de obras y experiencias, con servicios de consulta y registro que puedan utilizarse desde distintos canales. Todavía estamos definiendo y validando sus condiciones; el piloto y sus resultados están por delante.
Una memoria compartida y una capa de servicios reutilizable: la relación que orienta el diseño. Los accesos respetan los permisos de cada usuario. Es una propuesta por desarrollar y probar. Ampliar ilustración.
## Una empresa que integra conocimiento y ejecución
[**Climatización Norte**](https://www.facebook.com/CLIMATIZACIONNORTE.TERMOMECANICA/?locale=es_LA) es una empresa de profundo perfil técnico, especializada en instalaciones de climatización y energía solar. Trabaja principalmente en la Zona Norte de Buenos Aires, en viviendas de alta gama y en colaboración con estudios de arquitectura de primera línea. Son obras en las que el confort, la eficiencia energética y la integración con el proyecto arquitectónico necesitan resolverse en conjunto.
Una de sus fortalezas es la capacidad de desarrollar soluciones propias para aprovechar mejor la energía disponible. Un ejemplo es la recuperación del calor del sistema de refrigeración para climatizar el agua de la piscina. Al enfriar los ambientes, el sistema necesita transferir calor hacia otro lugar; una instalación preparada para recuperarlo permite utilizarlo donde hace falta calentar. La necesidad de refrigerar una parte de la vivienda contribuye así a resolver otra demanda del mismo conjunto.
Ese aprovechamiento requiere comprender cómo interactúan los equipos y diseñar su integración. Allí se reconoce el valor del trabajo de Climatización Norte: combinar conocimiento técnico, criterio de diseño y capacidad de ejecución para que los sistemas se complementen y respondan a las particularidades de cada obra.
## Descubrir dónde se concentra el trabajo
La empresa coordina cada obra mediante dos grupos de WhatsApp. En uno participa el arquitecto; en el otro, el personal propio o contratado que realiza la instalación. En ambos circulan mensajes, audios, fotografías y documentos sobre un mismo trabajo. Una condición puede aparecer en un texto, aclararse en un audio y terminar en una propuesta acompañada de un plano.
Dos ámbitos de conversación para una misma obra: arquitectura e instalación. El dibujo representa la forma de coordinación descrita; no identifica una obra particular. Ampliar ilustración.
Para responder una consulta, Federico puede necesitar reconstruir esas relaciones, recordar una decisión y comprobar si sigue vigente. Su conocimiento técnico permite resolver; su concentración también limita cuántos asuntos pueden avanzar al mismo tiempo.
Las 130 consultas corresponden a una jornada relatada, no a un promedio diario. Tampoco equivalen a 130 mensajes: una consulta puede ocupar varios intercambios, y un mensaje puede plantear varios asuntos. Antes de proyectar una mejora necesitamos observar esa composición durante días representativos.
El episodio de un conducto ayuda a reconocer otra consecuencia de la misma dificultad. Una arquitecta había limitado a 25 centímetros el descenso del cielorraso. Más adelante se propuso un conducto sin contemplar el espesor de la aislación, y la incompatibilidad se advirtió después de instalarlo. Según el relato de la empresa, reemplazarlo comprometía toda la ganancia de esa obra. La condición estaba escrita; faltó relacionarla con la propuesta antes de ejecutar.
Ambas escenas permiten buscar intervenciones concretas: recuperar lo acordado, reunir lo necesario para decidir y distribuir los asuntos según las responsabilidades. **Una oportunidad de mejora empieza a tomar forma cuando podemos explicar qué trabajo cambiaría y por qué ese cambio tendría valor.**
## La hipótesis: preparar mejor cada asunto
Una primera ayuda sería una bandeja de asuntos. Para cada uno reuniría la obra, el sector, la pregunta, los mensajes relacionados, las condiciones vigentes, los datos faltantes y el responsable. La IA ayudaría a interpretar los intercambios y prepararía propuestas que una persona pudiera revisar con sus fuentes a la vista.
| Situación encontrada | Ayuda que proponemos probar |
| --- | --- |
| La respuesta está en los antecedentes | Recuperar lo acordado y sus fuentes |
| Falta información para decidir | Identificar el dato pendiente y preparar una aclaración |
| Existe un criterio aprobado aplicable | Preparar una respuesta fundada en ese criterio |
| Otro responsable puede resolver | Proponer la derivación conforme a responsabilidades acordadas |
| Hace falta el criterio de Federico | Reunir antecedentes, alternativas y consecuencias para su revisión |
La clasificación no concede autoridad para ejecutar. Habrá que acordar qué puede resolver cada persona y qué decisiones requieren aprobación. Al comienzo evaluaríamos propuestas revisables; no se ha autorizado el envío automático de decisiones técnicas.
También necesitamos distinguir una contradicción de una información incompleta. Si falta una medida, la ayuda puede pedir su confirmación; no puede concluir que la instalación es compatible. La interpretación prepara la revisión y las comprobaciones calculables pueden apoyarse en reglas, una vez confirmados los datos y sus referencias.
Nuestra hipótesis es que este trabajo previo podría reducir pendientes y tiempo de intervención de Federico, manteniendo la calidad de las decisiones. La prueba debe mostrar qué consultas admiten esa ayuda y cuánto esfuerzo de revisión agrega.
## La memoria debe conservar cómo llegamos a una decisión
Llamamos **ingesta** a incorporar mensajes y archivos al sistema. Su primer propósito es asociarlos con la empresa, la obra y el grupo correctos, conservando su procedencia, fechas, participantes y relaciones de respuesta cuando esos datos estén disponibles. Una entrega repetida debe reconocerse como el mismo evento.
Sobre esos originales se construirían las transcripciones, los fragmentos consultables y los resúmenes. Cada interpretación necesita sus fuentes y su versión de procesamiento. Una propuesta, una aprobación y una modificación posterior tienen consecuencias distintas: necesitamos reconstruir qué se sabe y qué decisión sigue vigente, sin destruir la historia.
En una obra larga no sería razonable enviar todo el historial al modelo en cada consulta. La recuperación combinaría filtros de obra, sector y fecha con búsqueda por significado. Esta última usa representaciones numéricas del contenido, llamadas *embeddings*, para localizar antecedentes relacionados. Debemos recuperar intercambios con contexto: un «sí» aislado no permite saber qué se aprobó.
La memoria podría incorporar experiencias de otras obras: problema, condiciones, solución aplicada, resultado comprobado, limitaciones y responsable de validación. La semejanza entre dos relatos sirve para encontrar un antecedente; comprobar su aplicación al caso nuevo exige criterio técnico.
Los permisos forman parte de esa memoria. Un mensaje interno no se vuelve compartible con el grupo de arquitectura por haber servido para preparar una respuesta. Las consultas entre obras también deben limitarse a lo autorizado para cada usuario.
## Comprobar el canal antes de prometer la integración
WhatsApp es el canal que la empresa ya utiliza. Para esta integración hará falta dar de alta y configurar la cuenta en WhatsApp Business Platform y obtener de Meta el reconocimiento de **cuenta oficial de empresa (OBA, Official Business Account)** para su número. Es un requisito de [Groups API](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/get-started), cuya habilitación depende de la revisión de Meta. La [solicitud de OBA](https://developers.facebook.com/documentation/business-messaging/whatsapp/official-business-accounts) exige, entre otras condiciones, la verificación de la empresa y al menos 30 días de registro en la plataforma; crear la cuenta no habilita inmediatamente el uso de grupos.
El número deberá operar con Cloud API y habrá que comprobar la adecuación de los grupos. La existencia de la API empresarial no demuestra que podamos incorporar las conversaciones actuales con sus participantes y su historial. Esas condiciones forman parte de la factibilidad que necesitamos resolver antes del piloto.
Podemos ensayar recepción, duplicados y recuperación de archivos con eventos de prueba. Para iniciar la observación real necesitamos comprobar el recorrido desde el canal habilitado hasta una consulta que devuelva la fuente correcta. Si hacen falta nuevos grupos o invitaciones, ese esfuerzo forma parte de la adopción y de su costo. Telegram sigue siendo una alternativa por evaluar, considerando el cambio de hábitos que implicaría.
## Estimar el costo sin confundir una parte con el total
Antes de construir conviene conocer el orden de magnitud de los consumos y sus variables. Tomamos AWS bajo demanda, con Virginia (`us-east-1`) como región de referencia, importes en dólares y sin impuestos ni créditos promocionales. Son referencias para diseñar la medición; todavía no tenemos una factura del piloto.
Un ejemplo hipotético permite recorrer dos componentes:
| Material y supuesto | Cálculo | Costo parcial estimado |
| --- | --- | --- |
| 1.000 audios de 30 segundos, transcritos una vez | 500 minutos × USD 0,006/minuto | USD 3 |
| 1.000 fotografías con una primera lectura presupuestada en USD 0,003 | 1.000 × USD 0,003 | USD 3 |
La [referencia de Transcribe batch en Virginia](https://aws.amazon.com/transcribe/pricing/) permite calcular el primer renglón. Después de transcribir, interpretar decisiones o contrastarlas con antecedentes agrega procesamiento.
Para el segundo tomamos como orientación un [ejemplo de AWS con Nova 2 Lite](https://aws.amazon.com/blogs/machine-learning/pair-nova-2-lite-with-claude-for-cost-optimized-document-processing/), cuyo primer paso de extracción cuesta aproximadamente USD 0,0027 por imagen con los tokens allí indicados. Presupuestar USD 0,003 es un supuesto para una primera lectura. **Ese ejemplo no mide el análisis de fotografías de esta empresa**: interpretar un plano o revisar una solución técnica puede requerir otros modelos, más contexto y varias llamadas.
Los USD 6 de la tabla cubren solo esas operaciones. El costo de operar incluye además recepción, interpretación de textos, bases de datos, generación de embeddings, búsquedas, resúmenes, consultas, reintentos y registros. El almacenamiento acumula consumo mientras conservamos los originales; mil fotos de 2 MB incorporan aproximadamente 2 GB antes de copias y derivados. También hay que considerar desarrollo, soporte y trabajo humano residual.
### Mensajes de grupos: recibir y responder tienen costos distintos
Los mensajes que los participantes envían desde los grupos hacia el número empresarial **no tienen cargo de mensajería de Meta**, según sus [condiciones de precios](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing#how-meta-charges-for-messages). Recibir 1.000 o 100.000 mensajes representa USD 0 de mensajería entrante de Meta; su conservación y procesamiento sí consumen recursos en nuestro sistema.
Al enviar al grupo, Meta cuenta cada entrega a un participante. La tarifa consultada el 28 de octubre de 2026 para **mensajes de servicio a números argentinos es USD 0,026 por entrega**. Una alerta recibida por cinco personas costaría USD 0,13 una vez agotado el cupo gratuito. La [documentación de Groups API](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/pricing/) explica el cálculo por destinatario; la tarifa puede consultarse en el [calculador oficial](https://whatsappbusiness.com/products/platform-pricing/), seleccionando Argentina, USD y Service.
Desde el 1 de octubre de 2026, cada número empresarial dispone de 1.000 entregas mensuales gratuitas de servicio, compartidas entre grupos y conversaciones individuales. El ejemplo siguiente supone un número, cinco destinatarios argentinos por alerta, todo el cupo disponible y una alerta por cada cien mensajes recibidos. Los mensajes de servicio se envían dentro de la ventana de atención de 24 horas abierta o renovada por un mensaje del grupo.
| Mensajes entrantes al mes | Alertas enviadas | Entregas a participantes | Cargo de Meta |
| --- | --- | --- | --- |
| 1.000 | 10 | 50 | USD 0 |
| 100.000 | 1.000 | 5.000 | USD 104 |
En el segundo escenario se cobran 4.000 entregas después del cupo: 4.000 × USD 0,026 = USD 104. La frecuencia de alertas es un supuesto para calcular, no una regla de funcionamiento. Las plantillas de utilidad se cobran con sus propias condiciones y no consumen ese cupo como servicio gratuito; las invitaciones también deben contabilizarse. Estos importes no incluyen impuestos, AWS ni posibles cargos de intermediarios. Las tarifas deben revisarse al presupuestar.
El ensayo inicial puede mostrar las respuestas en una bandeja y reservar los envíos de WhatsApp para unas pocas comprobaciones controladas. Así podremos medir la ayuda sin agregar desde el comienzo el costo y las interrupciones de muchas alertas.
## Una prueba pequeña que produzca evidencia útil
Proponemos 30 días con una obra activa y sus dos grupos, más un conjunto pequeño de antecedentes históricos autorizados. El plazo es una propuesta; el piloto aún no comenzó. El primer recorrido útil sería capturar con fiabilidad, agrupar asuntos, recuperar evidencia y preparar revisiones. Los experimentos adicionales entrarían según lo que aprendamos.
1. **Observar el trabajo actual.** Registrar consultas, asuntos únicos, pendientes y tiempo activo de búsqueda, decisión y respuesta durante días representativos. Preparar preguntas y respuestas de referencia revisadas por una persona.
2. **Comprobar la captura y la recuperación.** Probar mensajes repetidos, fallos, archivos y permisos. Incorporar la actividad real cuando el canal esté habilitado y verificar las fuentes devueltas.
3. **Evaluar la bandeja con Federico.** Registrar propuestas aceptadas, corregidas y descartadas, derivaciones, datos faltantes y asuntos que siguen requiriendo su criterio. Un resumen diario por grupo y tres consultas diarias serían una carga inicial de ensayo, ajustable al uso real.
4. **Contrastar alternativas acotadas.** Comparar dos recorridos de audio sobre 50 a 100 audios autorizados y recuperación con y sin búsqueda semántica sobre las mismas preguntas. Contabilizar aparte las repeticiones del experimento.
5. **Conciliar calidad, esfuerzo y costo.** Relacionar consumo y facturación con resultados útiles y decidir qué conviene continuar, corregir o detener.
La comparación de audio contemplaría Transcribe seguido de extracción de información en Bedrock, frente a [Bedrock Data Automation](https://docs.aws.amazon.com/bedrock/latest/userguide/audio-processing.html) con una extracción equivalente. Nos interesan especialmente errores en números, unidades, negaciones, ubicaciones y aprobaciones. La prueba comparará el recorrido completo, incluida la corrección humana. En documentos conviene extraer el texto disponible antes de aplicar reconocimiento de texto a una imagen.
Para revisar el episodio histórico del conducto respetaríamos el orden de los mensajes, usando solo la información conocida antes de instalar. Evaluar conociendo el desenlace puede hacer parecer evidente una relación que entonces requería confirmación. Registraríamos advertencias oportunas, omisiones y falsas alarmas.
### Qué resultado justificaría continuar
La medición debe mostrar si bajan los pendientes, su antigüedad y el tiempo de intervención, comparando días y asuntos de complejidad semejante. Incluiremos el trabajo de todos los que revisan, corrigen y mantienen la información. Reducir el tiempo de Federico a costa de multiplicar el de otras personas cambiaría la evaluación.
También comprobaremos que los mensajes no se dupliquen, que los archivos estén disponibles o tengan un error explícito, que las respuestas permitan revisar sus fuentes y que los permisos se conserven. Las metas cuantitativas deben acordarse después de conocer la actividad y su dificultad; todavía no existe un porcentaje de mejora comprometido.
Liberar capacidad puede permitir atender más obras o trabajar con menos interrupciones. Ese tiempo no equivale por sí mismo a un ahorro de dinero ni a margen adicional. Para atribuir beneficio económico necesitaremos mostrar qué cambió efectivamente y compararlo con implementación amortizada en un período explícito, operación, soporte y revisión, evitando contar dos veces el mismo resultado.
## Arquitectura propuesta en AWS
La arquitectura separa recepción, procesamiento, conservación y uso del conocimiento. API Gateway recibiría los eventos y Lambda validaría su procedencia antes de enviarlos a SQS. Esa cola permite desacoplar la llegada de mensajes del trabajo posterior. Un proceso Lambda conservaría originales y adjuntos en S3, y mensajes normalizados, estados y derivados en DynamoDB bajo demanda. Los errores persistentes pasarían a una cola separada para revisión. La integración [Lambda con SQS](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html) requiere procesar sin duplicar efectos y tratar los fallos parciales.
Transcribe y Bedrock aportarían transcripción e interpretación según el experimento elegido. CloudWatch permitiría observar ejecuciones, errores y consumos registrados. Es una base propuesta por desarrollar, no una infraestructura desplegada para el cliente.
Disposición de arquitectura con iconos oficiales, límites de nube y región, y conectores rectos. Se separan recepción, procesamiento, conocimiento y consulta. El esquema omite las respuestas de los servicios de procesamiento y la configuración detallada de identidad y permisos. CloudWatch observa el conjunto. La conexión real de WhatsApp y las capacidades del piloto siguen pendientes de validación. Ampliar diagrama.
Para las obras largas evaluaríamos los [índices vectoriales nativos de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/VectorSearch.html) como alternativa a incorporar otra base. Esa opción agrega generación de embeddings, almacenamiento y consultas que deben medirse. La búsqueda por significado complementaría el acceso directo a decisiones vigentes y mensajes recientes; su utilidad se compararía con preguntas de referencia y evidencia recuperable.
La capa de servicios reuniría la lógica para consultar y registrar información. Desde una bandeja propia o, como evolución, desde ChatGPT mediante **MCP**, un protocolo para exponer herramientas y datos a un asistente. La empresa ya cuenta con un plan Business, según lo conversado; habrá que comprobar autenticación, permisos y disponibilidad en su espacio de trabajo. La [documentación oficial de OpenAI sobre MCP](https://developers.openai.com/plugins/build/mcp-server) orienta esa conexión.
Así también podrían incorporarse condiciones de clientes o antecedentes de reuniones que no llegan por WhatsApp. Agregar una nota y aprobar un cambio seguirían siendo operaciones diferentes, con autor, fecha y permisos. La misma lógica podría servir después a procesos automáticos y a un ERP como Odoo. El uso interactivo de ChatGPT y las llamadas de modelos del backend tienen consumos distintos; cada lectura de contexto desde MCP no exige por diseño otra llamada a Bedrock.
### Medir la operación desde su diseño
Cada operación registraría obra, grupo, etapa, contenido de origen, intento, modelo y versión. Mediríamos mensajes únicos, archivos, duración facturada de audio, páginas, tokens, búsquedas, reintentos y almacenamiento. Identificar los recursos y activar las [etiquetas de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) antes del ensayo permitiría contrastar esa medición con la factura; los servicios compartidos requieren atribución adicional por consumo.
El informe debería separar costo base mensual, costo por mil mensajes con la mezcla observada, por resumen y por consulta, y conservación a 30, 90 y 365 días. La proyección a cien mil mensajes debe conservar esa separación: multiplicar toda la factura por cien confundiría costos base, variables y acumulativos.
En la conversación propusimos USD 50 como presupuesto experimental por acordar, no como precio del servicio ni garantía de tope. Las [alertas de AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) pueden llegar con demora; tendrían que acompañarse de límites de procesamiento. Separaremos desarrollo, ensayos y operación normal, mostrando tanto lo facturado como el consumo a tarifas de lista.
## Aprender para decidir el siguiente paso
El caso permite recorrer cómo trabajamos en Idoneos: observar una dificultad concreta, comprender qué la produce, elegir una intervención y construir la evidencia para decidir. La primera prueba debe decirnos si reunir información y preparar asuntos permite aprovechar mejor el conocimiento de la empresa, con qué calidad y a qué costo.
El resultado de ese aprendizaje puede justificar ampliar una capacidad, modificar el recorrido o detener una línea que no aporta suficiente valor. La evolución del proyecto se apoyará en esas comprobaciones.
Siguiente paso
¿Una situación similar en la empresa?
Cuando las condiciones, las decisiones y los pendientes quedan repartidos entre conversaciones y documentos, recuperar lo necesario a tiempo puede exigir mucho trabajo. Podemos conversar sobre esa dificultad, identificar una primera mejora y definir cómo comprobar su utilidad.
En nuestros canales compartiremos los avances de este proyecto, las pruebas que realicemos y lo que vayamos aprendiendo durante su desarrollo. La invitación es a seguir ese recorrido junto con nosotros.
