Lessons on AI Applied to Satellite Imagery

Artificial Intelligence models for remote sensing have been delivering increasingly impressive results on academic benchmarks, which are generally standardized sets of data and metrics used to test models under controlled conditions. However, when these models move into an operational environment, where real decisions are made, a host of other technical, contextual and operational challenges emerge in day-to-day work.

In this article, I share some of the most important lessons I've learned from applying AI in geographic data pipelines. These are lessons that came from developing solutions of this kind, where models need not only to deliver the expected accuracy, but also to survive continuous use, cope with variations and imperfections in the data, and operate under schedule and resource constraints.

The overall goal here is to show that designing a robust solution from the start goes far beyond choosing good models. It means facing difficult decisions at every moment and at every stage of the process. Keywords such as trade-off sensitivity, accuracy, scalability, cost and reliability become constants in the vocabulary of anyone working on this type of project.

Lesson 1: Spatial resolution is a choice between detail and feasibility

Choosing the resolution is one of the first decisions we make, because it directly affects both the performance and the operating cost of the models. Higher resolution often increases project cost, either directly, through the need to purchase commercial imagery, or indirectly, through higher computational demand and longer processing times.

On the other hand, high-resolution images can capture subtler patterns in the environment, which can significantly help identify finer details. This richer detail clearly doesn't come without a trade-off. Models trained on high-resolution imagery tend to be more sensitive to noise and require more labeled data to generalize, besides imposing higher storage, training and data processing costs, which can reduce the system's scalability when running inference over large areas.

Lower resolutions, while less precise spatially, enable large-scale analyses at lower computational and financial cost. In many cases, the loss of resolution can be offset by robust modeling strategies, such as temporal aggregation, enrichment with auxiliary variables, or multiscale and multisensor approaches.

That is why the technical and economic feasibility of the chosen spatial resolution must always be weighed against the project's end goal, the patterns you want to identify, the mapping scale, and the operational infrastructure available to train, validate and run inference with the models. Committing early to an unsuitable resolution can compromise the entire workflow, both in terms of accuracy and operational sustainability.

Lesson 2: Temporal alignment is a trade-off between precision and availability

Many remote sensing projects require time series to capture recurring events, gradual changes or sudden impacts on the landscape. Sensors such as Sentinel-2 and Landsat, or even commercial imagery such as WorldView and Planet, offer different spatial and temporal resolutions, but rarely do they all capture images on the same dates. This forces a critical choice between:

• Strict temporal adherence: prioritizes date precision, but results in data scarcity.
• Extended temporal window: provides more observations, at the cost of more temporal noise.

Continuous monitoring use cases, such as detecting vegetation clearing or even open-pit mining operations, have one thing in common: they are directly tied to these temporal dilemmas. As a result, these analyses depend not only on model accuracy but directly on these choices, since in practice their main goal tends to be making decisions at the right time.

From a business perspective, there are usually a few metrics we track. One of them is latency. At the end of the day, latency is cost: delays in detecting events can lead to catastrophic financial, legal or even worse losses, compromising timely decision-making. That's why giving up some temporal precision to ensure availability may be not only acceptable but necessary in many cases.

Another important guideline to consider is frequency, because frequency often beats isolated precision. Detecting an anomaly with a five-day delay can be far more valuable than identifying it with just a one-day lag but only once a month. In practice, some systems can generate frequent alerts, even with lower point accuracy, which can be validated by a user and thus significantly improve the ability to respond to and mitigate problems.

Last but not least, there is always the risk of over-design, which, I probably don't need to say, but... it drives up costs and can make the operation unfeasible. Solutions that require perfect synchronization between sensors, or that operate with excessively narrow acquisition windows, tend to become so sophisticated and complex that the operation becomes unworkable once they clash with the real decision-making cycle and the physical limitations of the environment; many of these solutions end up becoming dysfunctional.

Lesson 3: Cloud masking is an "invisible decision"

For us, clouds are one of the few sources of noise we have no control over: we don't know when they will appear, or whether a given satellite pass will produce an image that lets us see the landscape at all. This is one of the main challenges of our daily work, since clouds are major sources of noise and errors in products derived from satellite imagery.

Clouds significantly alter spectral signatures, obstruct targets of interest and undermine model reliability, especially in tropical environments like ours, where they are persistent and seasonally frequent.

There are solutions, however: cloud masking. Although essential in many applications, it is often neglected or treated as a merely technical step. In practice, it is an invisible decision that directly affects the availability, representativeness and robustness of the analyses.

There are several approaches to cloud masking, but two types are the most common:

• Conservative masks: These masks remove any pixel with even the slightest suspicion of cloud or shadow, discarding all the brightest and darkest pixels. They tend to significantly reduce spectral contamination, but on the other hand they can eliminate large portions of valid pixels, especially in regions with heavy cloud cover, which can make consistent analyses unfeasible or create gaps.
• Permissive masks: Permissive approaches, on the other hand, preserve greater spatial and temporal coverage, but increase the risk of letting contamination in, since that information ends up treated as valid pixels. This can degrade model performance, introduce noise into time series patterns, and cause confusion between classes.

However, the choice between the two should not be locked into a single option applied to every type of problem. It should be contextual, data-driven and aligned with the end goal of the application. A poorly calibrated mask can be as harmful as no mask at all. Masking must therefore be treated as an integral part of the solution design, with its impacts on training, inference and metrics systematically validated.

Lesson 4: A model doesn't scale on its own

I wish I could train a model on a few samples over a region of interest and, just like that, have the solution ready. Unfortunately, things don't work that way.

For a solution to go into production, it can't be assessed on performance metrics alone. A classification or prediction model should not be judged solely by traditional indicators such as accuracy or F1-score.

Even technically robust, well-trained models become unfeasible if they take hours or days to process an area of interest. Most of the time, the biggest bottleneck isn't the model itself, but the time spent reading, preprocessing and writing data, and in the post-processing steps. That's why it is essential to use strategies such as:

• Windowed reading with rasterio.windows or GDAL;
• Splitting the data into spatially optimized tiles;
• Distributed parallel execution via multiprocessing or Dask.
• Using containers such as Docker to ensure reproducibility, environment isolation and easy deployment across different infrastructures.

The most important lesson is that for a model to be good, we need to design its pipelines robustly, taking into account several important aspects during development, such as:

• Load balancing per tile, ensuring an even distribution of processing.
• Processing tiles in batches, optimizing resource usage and making parallelization easier.
• Controlling memory usage during reads and writes, especially when dealing with very large regions of interest and large data volumes.
• Efficient parallelization, favoring strategies that maximize performance without introducing unnecessary overhead;
• Compatibility with orchestration systems such as Airflow, or serverless cloud pipelines, enabling automation, scaling, and monitoring of the workflow and costs.

In addition, frameworks should be chosen considering not only the data volume, but also the teams' technology ecosystem, operating cost, ease of maintenance, and even the use of containers as part of a DevOps and MLOps strategy.

Conclusion

Applying Artificial Intelligence to remote sensing projects goes far beyond reaching accuracy metrics in controlled environments. It is, above all, a continuous exercise in engineering, contextual decision-making, and balancing what is technically ideal against what is operationally feasible.

In the real world, models face unpredictable variations in the data, logistical constraints and scale requirements that rarely show up in more academic settings. Robust models are not born from good architectures alone, but from carefully designed pipelines that can handle uncertainty, noise and performance demands under pressure.

When you design a solution of this kind, remember that it is not a purely algorithmic task. It is an engineering practice that requires weighing cost, performance, accuracy and reliability. And, above all, one where simple but well-calibrated solutions almost always outperform sophisticated but fragile approaches in the face of continuous real-world use.