A tourist city does not operate according to the population recorded in its municipal register. It operates according to the number of people who are actually present at any given moment.
The difference can be substantial. In Benidorm’s population Digital Twin project, developed within the Smart Costa Blanca 2.0 framework, the project documentation uses a reference of 72,550 registered residents and a calibration peak of approximately 360,000 people present on 12 August 2023.
For a local authority, this is more than a statistical difference. It affects demand for services, pressure on specific areas of the city, mobility patterns and the ability to prepare for weekends, events and periods of particularly high occupancy.
The challenge is therefore to estimate present population, understand its distribution and anticipate how it may change. And to do so without confusing an indirect signal with a direct measurement, historical information with a current observation, or a technically accurate prediction with evidence that is sufficient for a decision.
This is the problem space addressed by iris360 Human Dynamics.
The platform brings together heterogeneous sources including water and electricity consumption, weather, calendars, events, tourism and mobility, with outputs designed to support municipal planning.
The purpose is not to collect data simply because it is available. It is to understand what each source contributes, what can reasonably be inferred from it and what evidence is required before an estimate is used in practice.
72,550 registered residents. A calibration peak of close to 360,000 people present on 12 August 2023.
Benidorm: understanding present population to plan more effectively
Registered population answers an administrative question: how many people have their residence formally recorded in a city. Operational planning requires different answers.
How many people are actually present today? How are they distributed? How many are residents, visitors or part of the floating population? How are people moving across the city? How might the situation change over the next few days?
Benidorm’s population Digital Twin is designed to bring distributed information together to estimate present population, understand overnight stays and visitor flows and explore future scenarios.
The intended uses are tangible: sizing cleaning and waste collection services, preparing beach services and anticipating requirements associated with events and peaks in attendance. The design also includes one-week population forecasts and dashboards covering floating population, overnight stay distribution and population flows.
Yet having more sources does not solve the problem on its own. The real challenge is understanding what each source actually observes.
Water consumption is not a people counter
Water provides a useful example. Consumption can provide information about demand, coverage or spatial pressure. But a change in water consumption cannot automatically be interpreted as an equivalent change in population.
Within Human Dynamics, water-related views are handled accordingly: as signals that may contribute to an estimate, rather than as direct measurements of individual occupancy. The project dossier also establishes an important principle: no individual source should be treated as a universal ground truth.
This has a practical consequence. A data platform needs to do more than integrate information. It needs to preserve its context.
A variable may be correctly stored and still be incorrectly interpreted. It may refer to an observation made that day or to information that became available later. It may be a cumulative figure or a component already included in another metric. A missing record may indicate no activity or simply a failure in the source.
If those distinctions disappear during integration, the model may learn from a representation of reality that differs from the one we intended to build.
From integrating data to understanding what the data means
The work carried out for iris360 Human Dynamics inventoried multiple data sources across an analysed universe of 959,208 records and structured part of the documentation through 18 Data Sheets. These records connect datasets with quality controls, usage rights, traceability and retention.
The purpose is not documentation for its own sake. Data Sheets make explicit some of the issues that can otherwise become invisible once multiple sources are combined into an integrated data environment: granularity, keys, time lags, variable semantics, aggregation rules and conditions of use.
It is useful here to distinguish between a data model and an AI model. The former defines the structure and meaning of the information. The latter uses that information to produce an estimate. The quality of the second necessarily depends on the first.
For this reason, data governance in an AI-enabled data platform cannot be treated as an administrative stage that happens after development. It is part of the model-building process itself.
Adapted historical data remains historical data
Time introduces another difficulty. The project dossier considers a 2026 reference layer constructed using historical FluxVision data from 2025. Its use requires the original data and date to remain available, the extrapolation to be identified, the relevant temporal variables to be recalculated and the resulting reference to be validated against real 2026 observations.
The documentation also records another limitation: a reference based on a peak-season period does not demonstrate that the same behaviour will generalise across the entire year.
This distinction matters. Adapting historical data may be useful when preparing an integration, training a model or progressing a pilot. It does not turn that historical information into a contemporary observation. A useful transformation should not erase the nature of the underlying evidence.
Maintaining the distinction between what was observed, what was transformed and what was inferred becomes essential once a platform starts producing predictions.
Different questions require different models
Estimating how many people are present in a city is not the same problem as understanding how those people are distributed, analysing origin-destination flows or estimating what effect may be associated with an event.
Human Dynamics therefore structures the work through four different Model Cards. The first addresses present population and aggregate composition. The second covers arrivals, departures and flows. The third focuses on spatial pressure and territorial distribution. The fourth considers the impact of events and scenarios.
This separation is methodological rather than documentary. A model that estimates total population correctly has not necessarily demonstrated that it can distribute that population across neighbourhoods with the same level of accuracy. Likewise, reproducing a pattern observed during an event is not sufficient to establish that the event caused the observed change.
Each problem requires its own evaluation criteria.
Accuracy requires context
For Benidorm, the evaluation plan does not stop at average predictive error. It distinguishes performance under normal conditions and at peak periods, while also considering uncertainty, robustness, privacy, security, seasonal changes, events and the loss of individual data sources.
A performance figure therefore needs to be interpreted together with the model version, the data used, the evaluation period, the test conditions and the known limitations. Otherwise, an apparently precise metric can create more confidence than the evidence supports.
Model Cards preserve this context both for the team developing a model and for those who may later use its outputs. They also force us to ask necessary questions. Does the model perform equally well outside peak season? What happens if a source disappears? Are we estimating a situation comparable to those represented in the training data, or are we extrapolating beyond them?
From individual models to the complete platform
A prediction does not emerge directly from an algorithm. Before it is generated, information has passed through data sources, transformations, rules, quality controls, normalisation processes and specific versions of the underlying datasets. Afterwards, interfaces, users, oversight mechanisms and decisions become part of the system.
This is why the documentation does not stop at datasets and models. The Human Dynamics System Card describes the architecture as a whole: from original data and quality and rights controls to normalised layers, training and evaluation matrices, models and the outputs delivered through iris360. It also covers activity logs, source monitoring, change detection, security, incident response and human oversight.
This perspective is aligned with the architecture of Benidorm’s Digital Twin, organised through bronze, silver and gold data layers: original information, cleaned information and indicators and models intended for use.
The traceability we are seeking does not stop at identifying which algorithm produced a number. It should make it possible to reconstruct which information and conditions ultimately allowed that number to become part of a decision.
What happens when a source is no longer reliable?
Consider a simple scenario. iris360 forecasts a significant increase in population over a weekend, while one of the relevant sources has not been updated for several days.
The forecast may still exist. What has changed is the context in which it should be interpreted. In our design, that limitation needs to accompany the result. It should not disappear behind a convincing visualisation or remain invisible to the person using the information.
Human oversight does not simply mean placing a person in front of a dashboard. It means giving that person the ability to interpret an estimate, review it, modify a decision, limit the system or suspend its use when conditions require it.
This approach is also consistent with the human-oversight principles established by the EU AI Act for certain high-risk AI systems.
Understanding patterns without turning a city into individual tracking
Within the defined scope of this project, Human Dynamics operates using aggregated information. Biometric identification, sensitive categorisation and emotion inference are outside the project scope. The documentation also excludes age, gender, nationality and municipality from the predictive core of the Orange FluxVision reference layer.
The availability of a variable is not, in itself, sufficient reason to use it. Working with aggregated information does not remove every privacy question either. Combining sources can create risks that are not visible when each dataset is assessed independently.
The relevant question is therefore not only what information can be used. It is also what level of detail is genuinely required for the purpose of the service.
Responsible AI applied to a data platform
In this context, Responsible AI becomes less of a general statement and more of a practical approach to platform design.
Data Sheets explain what is known about the datasets. Model Cards document what is known about the behaviour and limitations of individual models. The System Card connects both with the operation of the complete service and with the people who interact with it. Traceability, version control, evaluation, privacy, monitoring and human oversight provide the surrounding controls.
These mechanisms relate directly to areas addressed by the EU AI Act, including data governance, technical documentation and human oversight for certain systems. But their usefulness is not limited to regulatory compliance. They are required to answer a more fundamental question: what evidence supports the use of a prediction under a particular set of conditions?
From pilot to production: documentation does not replace validation
The Human Dynamics dossier also distinguishes between defining a system and demonstrating that it is ready for production. The existence of an architecture, a Data Sheet, a Model Card or a System Card does not itself prove that the required tests have been executed or passed.
The methodology therefore considers evaluation in shadow mode, where models can operate in parallel without automatically turning their outputs into operational decisions. The purpose is to observe their behaviour, compare their outputs with real-world data and gather evidence before productive use is approved.
Within the dossier, that progression is conditional on materialised and traceable data, documented rights, linked model artefacts, real-world validation, reproducible testing, independent review and acceptance of residual risk.
Documentation should not be used to justify a decision retrospectively. It should help determine whether the conditions exist to make that decision in the first place.
From a data platform to understanding and anticipation
The Benidorm case provides a clear illustration of the role a platform such as iris360 can play once data is used not only to describe what has happened, but also to understand what is happening and explore what may happen next.
iris360 ingests and unifies information from multiple sources, enables that information to be monitored and contextualised, and provides a common foundation for predictive models and Digital Twins.
Within Human Dynamics, this architecture is being applied to a specific problem: understanding the difference between the administrative population of a city and the population actually using the territory. That leads to operational questions:
- How many people are present?
- Where are they?
- How are they moving?
- How is pressure distributed across the city?
- What variation may be associated with a particular event?
- And what may happen over the coming days?
Artificial intelligence expands our ability to answer these questions. It also requires us to be more precise about the evidence behind the answers.
The objective is not for Benidorm to trust an estimate because an AI model produced it. The objective is for that estimate to be usable because its origin is understood, its limitations remain visible and there are mechanisms to respond when those conditions change.
Español