Nuria Peña, responsable financiera de Contoso Airlines, lleva meses haciendo la misma pregunta en el comité y recibiendo la misma respuesta imprecisa. Cuando se aprobó la migración, alguien puso en una diapositiva «unos 8.500 € al mes». La factura media del primer trimestre real fue de 17.500 € al mes: exactamente el doble. Nadie mintió. Simplemente, la estimación se hizo sumando máquinas virtuales y bases de datos, que es lo que todo el mundo estima, y se olvidó todo lo demás: el firewall, el bastión, la puerta de enlace global, la ingesta de registros, la salida de datos y un clúster de Kubernetes cuyos nodos alguien creía que eran «parte de AKS».

Esta lección enseña a estimar antes de desplegar. Verás cómo se factura Azure de verdad —qué unidad de medida usa cada familia de servicios—, los tres tipos de coste que casi nadie estima, el manejo completo de la calculadora de precios, la estimación reconstruida de toda la plataforma de Contoso línea por línea, la calculadora de coste total de propiedad para comparar contra el centro de datos de Barcelona, por qué la misma máquina cuesta distinto en dos regiones, cómo automatizar estimaciones con la API de precios minoristas y, sobre todo, cómo se documenta el margen de error, porque una estimación sin supuestos escritos no es una estimación: es una cifra.

Aviso sobre los precios de esta lección y de todo el módulo: todas las cifras en euros que aparecen aquí son orientativas y ficticias, elegidas para que los órdenes de magnitud y las proporciones sean didácticos. Los precios reales de Azure cambian con frecuencia, varían por región, por moneda, por tipo de oferta y por descuentos contratados. Ninguna cifra de este módulo debe usarse para decidir nada: consulta siempre la calculadora oficial de precios de Azure y tu propio acuerdo comercial.

1. Por qué estimar antes de desplegar
2. Cómo se factura Azure de verdad: unidades de medida
3. Los tres costes que casi nadie estima
4. La calculadora de precios de Azure, paso a paso
5. La estimación completa de Contoso Airlines
6. La calculadora de coste total de propiedad
7. Precios por región: la misma VM a dos precios
8. La API de precios minoristas
9. El margen de error y los supuestos escritos
10. La estimación como parte del diseño
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

En un centro de datos propio, gastar dinero exige una orden de compra, una firma y varias semanas. En Azure exige tres clics. Esa es toda la diferencia, y es enorme: el control del gasto se ha desplazado del departamento de compras al teclado del ingeniero, y nadie le avisó al ingeniero.

La consecuencia es un patrón que se repite en todas las organizaciones que migran:

La estimación es la única palanca que actúa en la primera fila. Dicho de otro modo: la factura más difícil de corregir es la que ya has provocado. Un nivel de redundancia elegido a la ligera el primer día se convierte en una migración de datos el año siguiente.

Y hay un segundo motivo, menos obvio y más importante: estimar obliga a entender la arquitectura. Cuando Marta Ríos rehízo la estimación de Contoso con la calculadora, descubrió tres cosas que llevaban meses ahí sin que nadie las viera —una réplica geográfica de base de datos que costaba casi lo mismo que la principal, un grupo de nodos de AKS dimensionado para una prueba de carga que terminó en marzo, y una puerta de enlace de VPN sin ninguna conexión activa—. Estimar es auditar el diseño con una calculadora en la mano.

El error de fondo de la estimación fallida de Contoso fue mental: se pensó en Azure como en un catálogo de máquinas con precio mensual. Azure factura unidades de consumo, y cada familia de servicios usa la suya. Hasta que no interiorizas la tabla siguiente, no puedes estimar nada.

Tres lecturas de esta tabla que cambian la forma de estimar:

• La unidad no siempre es el recurso que ves. No pagas app-contoso-reservas-pro; pagas plan-contoso-reservas-pro, y da igual que alojes una aplicación o cinco.
• Casi todo tiene una segunda unidad. El almacenamiento tiene GB y transacciones. El firewall tiene horas y gigabytes procesados. La base de datos tiene cómputo y almacenamiento y copias. Estimar solo la unidad principal produce sistemáticamente estimaciones bajas.
• Algunas unidades no son proporcionales al uso que percibes. Una consulta mal escrita en Synapse sin servidor lee 2 TB y cuesta más que un día entero de máquinas virtuales, aunque el usuario solo haya pulsado «actualizar».

De la estimación fallida de Contoso, casi la mitad de la desviación vino de tres partidas que ni siquiera aparecían en la hoja de cálculo original.

Salida de datos (egress). El tráfico hacia Azure es gratuito; el tráfico desde Azure hacia internet, no. Y tampoco es gratuito el tráfico entre regiones, ni en muchos casos entre zonas de disponibilidad. Como se anticipó en el módulo 2, esta es la sorpresa habitual de la factura, porque no aparece en ningún recurso: no hay un objeto llamado «salida de datos» en el portal al que mirar. En Contoso la produce todo esto a la vez: cada tarjeta de embarque descargada por un pasajero, cada respuesta de la API de disponibilidad a los agregadores externos, la replicación de db-reservas a North Europe, la replicación geográfica de acrcontosopro y las exportaciones nocturnas hacia el sistema de facturación local. Se estima con una regla sencilla: cuántos objetos salen al mes × tamaño medio, y se documenta el supuesto.

Transacciones y operaciones. Los GB de una cuenta de almacenamiento se estiman bien; las transacciones, casi nunca. Y en cargas con muchos objetos pequeños —que es exactamente el caso de las tarjetas de embarque— las transacciones pueden superar al almacenamiento. Peor aún: los niveles fríos abaratan el GB-mes y encarecen la transacción, así que un ciclo de vida mal ajustado que mueva a Cool datos que aún se leen mucho puede subir la factura. Lo mismo aplica a las operaciones de Key Vault, a las peticiones de Cosmos DB y a las operaciones de Defender for Cloud sobre Storage.

Las funciones «gratis» que arrastran un recurso de pago. Este es el más traicionero, porque el servicio anuncia coste cero y lo cumple:

La regla que hay que grabarse: cuando actives algo gratuito, pregunta siempre qué consumo genera aguas abajo. Las configuraciones de diagnóstico del módulo 7 son gratis y produjeron la tercera partida más cara de la plataforma.

La calculadora de precios de Azure (azure.microsoft.com/pricing/calculator) es una herramienta pública, sin necesidad de cuenta, que permite montar una estimación completa. Es engañosamente simple, y usarla bien tiene método.

El procedimiento que sigue Marta:

1. Buscar el servicio y añadirlo. La calculadora tiene un catálogo por categorías y un buscador. Añade cada servicio de la arquitectura, incluidos los que «no cuestan» —para dejar constancia de que se han considerado—.
2. Configurar región, nivel y cantidad. Aquí está el 90 % del trabajo. Para una VM: región, sistema operativo, tipo de instancia, número de instancias, horas al mes (730 si es 24x7, unas 176 si solo es horario laborable), tipo de disco y número de discos, y la opción de ahorro (pago por uso, reserva de 1 o 3 años, plan de ahorro, spot). Este selector es lo que conecta esta lección con la 08-03.
3. Agrupar por componente. La calculadora permite crear grupos y renombrarlos. Contoso usa un grupo por bloque de la arquitectura: Frontal web, API de disponibilidad, Datos, Red y seguridad, Observabilidad, Integración e IA, Desarrollo. Sin grupos, una estimación de cuarenta líneas es ilegible y nadie la revisa.
4. Fijar moneda, región de facturación y programa de licencias. La calculadora aplica el tipo de oferta (pago por uso, Enterprise, CSP) y permite indicar un porcentaje de descuento negociado.
5. Guardar y compartir. Con una cuenta Microsoft, la estimación se guarda y se obtiene un enlace. Es lo que se adjunta a la revisión de arquitectura.
6. Exportar a hoja de cálculo. El botón de exportación genera un .xlsx con una fila por línea, que es el formato con el que Nuria puede trabajar y comparar meses.

Dos advertencias de uso. La primera: la calculadora no conoce tu carga; solo multiplica lo que le digas. Si pones 730 horas para una máquina que en realidad estará encendida 200, la culpa no es de la herramienta. La segunda: hay servicios cuyo coste no se puede estimar sin datos previos —salida de datos, transacciones, tokens, GB ingeridos—; para esos, la calculadora te obliga a introducir una cantidad, y esa cantidad es un supuesto que hay que documentar (apartado 9).

Marta rehizo la estimación de la plataforma tal y como está hoy. El resultado, en euros mensuales orientativos y ficticios:

De dónde sale cada bloque merece comentario, porque el aprendizaje está ahí:

• Las cinco líneas que sorprenden son, por este orden: log-contoso-pro (1.500 €, más que la mitad de la plataforma web), fw-contoso-hub-pro (1.010 €, que factura por hora y por gigabyte procesado tanto si pasa tráfico como si no), el clúster aks-contoso-operaciones (1.980 €, porque los nodos son máquinas virtuales que se pagan íntegras), bastion-contoso-pro (205 € por un servicio que se usa quince minutos al día) y fd-contoso-global (385 € por el nivel Premium que exige el WAF).
• La réplica de db-reservas cuesta 1.180 €, un 80 % de la principal. Es el precio explícito de la decisión de recuperación del módulo 7, y ahora se ve en euros: exactamente la clase de dato que permite una conversación honesta con el negocio.
• La salida de datos (700 €) no corresponde a ningún recurso. Nadie la habría estimado sin la tabla del apartado 2.
• Todo el entorno de desarrollo son 285 € gracias al runbook Detener-IniciarEntornosDev y al nivel sin servidor con pausa automática. Sin esas dos decisiones rondaría los 1.100 €.

Comparado con los 8.500 € de la diapositiva original, la diferencia se explica casi entera con cinco líneas: AKS, Log Analytics, firewall, la réplica de base de datos y la salida de datos. Ninguna de ellas es un recurso que el equipo hubiera «pedido»; todas son consecuencias de decisiones de arquitectura correctas que nadie tradujo a dinero.

Nuria hizo la pregunta inevitable: «¿no era más barato el centro de datos de Barcelona?». Para responderla existe la calculadora de coste total de propiedad (TCO), una herramienta distinta de la de precios: se describe la infraestructura local —servidores, núcleos, memoria, almacenamiento, ancho de banda, licencias— y devuelve una comparación a varios años frente al equivalente en Azure.

El valor de la herramienta no está en el número que produce, sino en que obliga a incluir los costes que la contabilidad local nunca imputa al proyecto:

Con la calculadora de TCO y esos ajustes, la comparación de Contoso quedó así (cifras orientativas y ficticias, anuales):

La conclusión que Contoso escribió, y que conviene copiar literalmente en cualquier informe: la comparación no es «Azure es más barato», sino «Azure es más barato que un centro de datos honestamente contabilizado, y además convierte inversión en gasto operativo, elimina la sobrecapacidad y aporta capacidades —redundancia geográfica, escalado en minutos, servicios administrados— que el centro de datos no tenía a ningún precio». Comparar solo hardware contra facturas de Azure es la forma más habitual de mentirse.

El mismo tamaño de instancia cuesta distinto en West Europe, en North Europe, en Suecia Central o en Estados Unidos. Las causas son reales: coste de la energía y del terreno, impuestos, madurez del centro de datos, tipo de cambio y demanda local.

Índice orientativo y ficticio tomando West Europe como 100 para una misma VM:

La tentación es obvia: mover cargas a la región más barata. Antes de hacerlo, cuatro frenos que Contoso aplicó:

• Latencia. La web de reservas sirve a pasajeros europeos. Un 13 % de ahorro en cómputo no compensa 120 ms adicionales en cada compra.
• Residencia del dato. Los datos personales de pasajeros y tripulaciones no salen de la UE. Es una restricción legal, no una preferencia, y la impone la directiva de regiones permitidas del módulo 4.
• Salida entre regiones. Repartir componentes que se hablan mucho entre dos regiones convierte tráfico interno gratuito en tráfico entre regiones facturado.
• Disponibilidad del servicio. No todos los servicios ni todos los tamaños existen en todas las regiones, y las zonas de disponibilidad tampoco.

La regla práctica: la región se elige por latencia, residencia del dato y disponibilidad de servicios, y solo se usa el precio como criterio de desempate, o para cargas que no tienen ninguna de esas ataduras —por ejemplo, un procesamiento por lotes nocturno sin datos personales—.

Para automatizar estimaciones —o para comparar regiones sin abrir la calculadora cuarenta veces— Azure publica la API de precios minoristas (Retail Prices), pública, sin autenticación y sin coste. Devuelve los precios de tarifa oficial, sin tus descuentos negociados.

El parámetro $filter usa sintaxis OData y admite serviceName, armRegionName, armSkuName, meterName, priceType (Consumption, Reservation, DevTestConsumption) y reservationTerm. La cláusula select de jq descarta las variantes con licencia de Windows, que aparecen mezcladas con las de Linux y son el error de lectura más común.

Bucle equivalente sobre varias regiones —el uso que más rendimiento da— sustituyendo armRegionName eq '$REGION' dentro de un for REGION in westeurope northeurope swedencentral eastus, tomando [.Items[].retailPrice] | min y multiplicando por 730 horas para obtener el mes medio. La respuesta viene paginada mediante el campo NextPageLink, así que para consultas amplias hay que iterar. Un uso muy práctico: mantener en contoso-infra un script que, en cada solicitud de incorporación de cambios que modifique un .bicep, consulte los precios de las SKU declaradas y publique la estimación como comentario automático en la propia solicitud (apartado 10).

Cada elemento devuelto tiene esta forma. Fíjate en unitOfMeasure: es la clave para no equivocarse de tres órdenes de magnitud. Hay medidores expresados en «1 Hour», otros en «1 GB/Month», otros en «10K» operaciones y otros en «1M» tokens. Multiplicar sin leer esa columna es el error clásico de quien automatiza estimaciones por primera vez.

Una estimación es un modelo, y todo modelo tiene error. La diferencia entre una estimación profesional y una cifra improvisada es que la primera declara su error y sus supuestos.

Los componentes de la estimación de Contoso se clasifican por previsibilidad:

Y así se estima lo variable, que es donde todo el mundo se rinde:

• Autoescalado: no se estima el máximo ni el mínimo, sino el perfil horario esperado. Contoso documentó: 2 instancias de 00:00 a 07:00, 6 de 07:00 a 22:00, y un perfil apertura-temporada-verano con media de 14 durante tres semanas. La media ponderada mensual salió 6, y por eso la línea dice 6 y no 20.
• Transacciones y salida: se estiman desde el negocio, no desde la infraestructura. «92.000 reservas al mes × 1,4 tarjetas por reserva × 180 KB» da los gigabytes de salida de tarjetas; el resto se acota con un factor.
• Tokens: consumo por interacción × interacciones esperadas, con un límite duro configurado en el servicio para que el error no sea ilimitado.

El colchón de Contoso: sobre los 17.450 € base, un 15 % de contingencia da 20.070 €/mes, y esa es la cifra que se llevó al comité. Es deliberadamente conservadora, y responde a una asimetría real: quedarse corto en una estimación cuesta credibilidad ante finanzas; pasarse un poco produce una buena noticia. La regla escrita fue: «se presupuesta la estimación con colchón; se persigue la estimación base».

Los supuestos van en el documento, no en la cabeza:

Ese fichero vive junto a las plantillas en contoso-infra. Su valor aparece tres meses después, cuando la factura no cuadra: se compara el supuesto con la realidad y se sabe qué falló, no solo cuánto.

Que el coste deje de ser una sorpresa exige integrarlo en dos momentos del proceso, no en una revisión anual.

En la revisión de arquitectura. Ninguna propuesta se aprueba en Contoso sin una estimación adjunta con sus supuestos y, cuando hay alternativas, sin una tabla comparativa. Ejemplo real del diseño de la API de disponibilidad:

Fíjate en que no ganó la opción más barata, y ese es el punto: la estimación no decide, informa. Lo que sí es inaceptable es decidir sin ella.

En la solicitud de incorporación de cambios de infraestructura. Toda modificación de un .bicep en contoso-infra (05-06) pasa por una comprobación automatizada que compara las SKU declaradas contra la rama principal y comenta el impacto:

La salida se publica como comentario en la solicitud, con el formato de tabla markdown ya montado. El efecto cultural es mayor que el técnico: quien propone un cambio ve su precio antes de que nadie se lo pregunte, y la conversación sobre coste ocurre en el momento en que corregirlo es gratis.

• Estimar solo el cómputo y las bases de datos. Es exactamente el error que duplicó la factura de Contoso. Recorre la tabla de unidades del apartado 2 servicio por servicio.
• Olvidar la salida de datos. No tiene recurso propio, no aparece en el portal como objeto y suele ser una de las diez primeras partidas.
• Confundir el recurso con la unidad facturada. Se paga el plan, no la aplicación; los nodos, no el clúster; el vCore-hora, no la base de datos.
• Poner 730 horas a todo, o estimar el máximo del autoescalado. Lo primero infla los entornos apagados de noche; lo segundo produce cifras que nadie se cree y desprestigian la estimación entera. Estima el perfil, y declara el máximo como riesgo.
• Leer mal unitOfMeasure en la API. «1M tokens» y «1K operaciones» conviven en la misma respuesta.
• Activar algo gratuito sin mirar aguas abajo. Las configuraciones de diagnóstico son gratis; la ingesta que provocan, no.
• Consejo: agrupa la estimación por componente de arquitectura, no por servicio de Azure. Nadie discute «Storage»; todo el mundo discute «cuánto cuesta la API de disponibilidad».
• Consejo: guarda la estimación con enlace y expórtala a hoja de cálculo el día que la haces, y revísala cuando cambie la arquitectura, no cuando llegue la factura.

Ejercicio 1. Estima con la calculadora oficial —usa tu región y tu moneda— un entorno de desarrollo equivalente al de Contoso: un plan de App Service básico, una base de datos SQL sin servidor con pausa automática, una cuenta de almacenamiento LRS de 200 GB y una VM de 2 vCPU encendida solo en horario laborable. Agrupa por componente, exporta y anota qué tres supuestos has tenido que inventarte.

Ejercicio 2. Contoso Millas (centro-coste=CC-2077) va a lanzarse: web en App Service, PostgreSQL flexible, blobs de justificantes, una Function que calcula puntos, un Event Grid y un panel en Log Analytics. Construye la lista de todas las unidades de medida que habrá que estimar, marcando cuáles son fijas, variables acotadas y variables abiertas, y qué margen aplicarías a cada grupo.

Ejercicio 3. Un compañero propone mover vmss-api-disponibilidad-pro de West Europe a East US porque «cuesta un 13 % menos». Escribe la respuesta técnica y económica: qué costes nuevos aparecen, qué restricciones lo impiden y qué cargas de Contoso sí serían candidatas legítimas a esa mudanza.

Solución 1: el ejercicio importa por los supuestos, no por el total. Los tres que inevitablemente hay que inventarse son: (1) horas de la VM —176 h al mes con el patrón laborable de 8 h × 22 días, frente a las 730 que la calculadora propone por defecto—; (2) segundos de cómputo de la base sin servidor, que dependen de cuántas horas al día trabaja el equipo y de la ventana de pausa automática configurada, y que en desarrollo suele quedar en un 15-25 % del mes; y (3) transacciones del almacenamiento, que la calculadora pide en operaciones de escritura, lectura y listado y que en desarrollo nadie ha medido nunca. Además hay dos costes que casi seguro se han omitido y hay que añadir: el disco gestionado de la VM, que se factura aunque la máquina esté desasignada, y su IP pública si la tiene. Comprobación de sensatez: en un entorno así, el disco y la base de datos suelen pesar más que el cómputo, precisamente porque el cómputo se apaga y el almacenamiento no.

Solución 2: unidades por servicio y su clasificación. Fijas (±5 %): hora del plan de App Service; vCore-hora y GB-mes de PostgreSQL flexible si está aprovisionado; réplica de alta disponibilidad si se activa. Variables acotadas (±25 %): ejecuciones y GB-segundo de la Function si está en plan de consumo —acotada porque el número de canjes tiene un techo conocido—; operaciones de Event Grid; GB-mes de los blobs, que crecen de forma previsible al ritmo de canjes. Variables abiertas (±50 %): transacciones del almacenamiento, que en justificantes pequeños pueden superar al GB-mes; GB ingeridos en log-contoso-pro por las configuraciones de diagnóstico del proyecto, que es la partida que más se subestima; y salida de datos por la descarga de justificantes. Costes gratuitos con consumo aguas abajo que hay que declarar aunque valgan cero: Event Grid tiene una franja gratuita generosa, las etiquetas y directivas no cuestan, pero la asignación diagnostico-app-service heredada de la iniciativa «Base de gobernanza de Contoso» generará ingesta desde el primer día. Margen global recomendado: 15 % sobre el total, con los supuestos de canjes mensuales y tamaño medio de justificante escritos en el documento.

Solución 3: el ahorro del 13 % se aplica solo a la línea de cómputo (1.320 € → unos 1.150 €, unos 170 € al mes), y contra eso aparecen costes nuevos: salida entre regiones por cada consulta de disponibilidad que el VMSS haga a db-reservas y a cosmos-contoso-tarifas-pro, que siguen en West Europe —tráfico hoy interno y gratuito que pasaría a facturarse y que, con el volumen de la API, se come el ahorro con holgura—; latencia de ida y vuelta transatlántica en cada petición, que degrada la disponibilidad mostrada al pasajero; y doble operación, porque habría que replicar red, NSG, puntos privados, bastion, reglas de fw-contoso-hub-pro y configuraciones de diagnóstico en una segunda región. La restricción que lo cierra sin discusión es de cumplimiento: los datos de pasajeros no salen de la UE, y la directiva de regiones permitidas del módulo 4 denegará el despliegue. Cargas que sí serían candidatas legítimas: procesos por lotes nocturnos sobre datos ya anonimizados, agentes de compilación autohospedados de contoso-reservas-ci —que además pueden ir en instancias de acceso puntual (08-03)—, y entrenamientos o pruebas de carga puntuales sin datos personales. Regla general: se mueve por precio lo que no tiene latencia crítica, ni datos regulados, ni conversación intensa con recursos de otra región.

Ya sabes por qué la estimación es la única palanca que actúa cuando corregir todavía es gratis, y por qué el error de Contoso —duplicar la previsión— no fue de cálculo sino de modelo mental: Azure no es un catálogo de máquinas con precio mensual, sino un conjunto de unidades de consumo. Tienes la tabla de esas unidades por familia de servicio —hora de instancia, hora de plan, GB-mes, transacción, unidad de solicitud, TB leído, GB ingerido, GB de salida, ejecución, token, instancia protegida—, la advertencia de que casi todo tiene una segunda unidad que nadie estima, y los tres costes que se olvidan siempre: la salida de datos, que no tiene recurso al que mirar; las transacciones, que en objetos pequeños superan al almacenamiento; y las funciones «gratuitas» que arrastran consumo aguas abajo, con las configuraciones de diagnóstico como ejemplo perfecto.

Manejas la calculadora de precios con método —buscar, configurar región, nivel, cantidad y horas, agrupar por componente, fijar moneda y oferta, guardar, compartir y exportar— y has visto la estimación completa de Contoso: 17.450 €/mes orientativos, con las cinco líneas que sorprenden identificadas —Log Analytics, el firewall, los nodos de AKS, el bastión y Front Door— más la réplica de db-reservas, que cuesta el 80 % de la principal y pone precio explícito a la decisión de recuperación del módulo 7. Sabes usar la calculadora de coste total de propiedad y qué costes ocultos del centro de datos hay que sumar para que la comparación sea honesta: energía, personal, espacio, renovación, sobrecapacidad y riesgo. Entiendes por qué la misma VM cuesta distinto en cada región y por qué la región se elige por latencia, residencia del dato y disponibilidad, con el precio solo como desempate; y puedes automatizarlo con la API de precios minoristas, vigilando siempre unitOfMeasure. Por encima de la herramienta llevas lo que convierte una cifra en una estimación: el margen de error declarado, la forma de estimar lo variable a partir del perfil horario y del negocio en lugar del máximo teórico, el colchón del 15 % que llevó los 17.450 € a los 20.070 € presupuestados, y el fichero de supuestos y riesgos versionado junto a las plantillas.

Pero una estimación, por buena que sea, sigue siendo una hipótesis. La pregunta de Nuria —«¿por qué sube la factura cada mes?»— solo se responde con datos reales: qué se gastó, en qué recurso, de qué equipo, en qué día y por qué. Eso es Azure Cost Management, y es la lección siguiente: la jerarquía de facturación y su diferencia con la de recursos, el análisis de costes agrupado por servicio, ubicación, grupo de recursos y etiqueta —donde por fin se cobra la disciplina de centro-coste=CC-1042 sembrada en el módulo 1 y forzada por la política hereda-centro-coste del módulo 4—, los presupuestos con sus alertas automatizadas, el reparto entre equipos, las exportaciones a stlagocontosopro y la detección de anomalías. De estimar el coste pasamos a medirlo.