Cloud AI is the practice of running model training, fine-tuning and inference on infrastructure operated by a cloud provider rather than on servers a team owns, and for engineering teams in Portugal the decision that matters is placement: provider APIs for most product features, managed GPU platforms for custom models, and rented spot capacity for fault-tolerant training runs. The economics reward attention, because cloud AI cost optimization levers such as spot pricing and batch inference routinely halve monthly bills, while EU rules now impose obligations with fixed dates. The buyer base keeps widening: Eurostat survey data shows 52.74% of EU enterprises used paid cloud computing services in 2025, an increase of 7.42 percentage points over 2023, and every one of those enterprises is a candidate host for AI workloads layered on top of an existing cloud estate.
Where Cloud AI Workloads Run
Three placement patterns cover almost every production system. Model APIs turn inference into a per-token service and shift capacity planning to the vendor; managed GPU platforms such as SageMaker, Vertex AI and Azure Machine Learning give control over fine-tuning and serving without cluster administration; and raw GPU instances on EC2, Google Cloud or Azure expose the full stack, from driver versions to queueing, to the team that rents them. Each step down that ladder buys cheaper marginal compute and more operational surface.
| Placement | Best fit | Cost profile | Operational burden |
|---|---|---|---|
| Provider model APIs | General text, code and analysis features | Per-token, predictable, batch discounts available | Low: keys, quotas, retry logic |
| Managed GPU platforms | Custom fine-tunes and controlled endpoints | Per-hour plus platform overhead | Medium: images, endpoints, autoscaling |
| Raw GPU instances | Large training runs, latency-critical serving | Highest variance, deepest spot discounts | High: scheduling, checkpointing, node health |
Match placement to workload shape rather than to team preference. Interactive product features belong on APIs, where scaling, model upgrades and rate limits are the vendor’s problem. Research fine-tunes belong on managed platforms until reproducibility demands tighter control. Only workloads with proven fault tolerance should graduate to raw instances, because that is where interruption handling, image pinning and cluster monitoring become the team’s responsibility. Output reliability is a second placement factor: our comparison of structured outputs across Anthropic and OpenAI APIs shows when schema enforcement at the API layer removes the need for brittle post-processing in the serving path.
Cutting Training and Inference Costs
Discounts are structural, not negotiated. Amazon EC2 Spot Instances are spare cloud capacity offered at up to a 90% discount compared to on-demand prices. AWS publishes the interruption contract in its Spot Instances documentation: reclaimed capacity comes with a two-minute warning, so the real cost control on a multi-day run is checkpoint frequency, not the hourly rate. A training pipeline that checkpoints every few minutes and resumes from object storage converts an interruption from a disaster into a few minutes of lost progress, which is why mature teams treat spot as the default and on-demand as the exception for time-critical runs.
Asynchronous workloads deserve their own lane. Anthropic’s Message Batches API reduces costs by 50% for asynchronous work, with most batches finishing in less than 1 hour and each batch limited to 100,000 requests or 256 MB. The batch processing documentation also defines a 24-hour completion window and 29-day result retention, so pipelines should treat retrieval as scheduled work rather than as an event to block on. Evaluation suites, document enrichment, classification backfills and nightly summarization are the natural fits; interactive chat is not. For queue design, idempotency keys and retry budgets, our guide to LLM batch API inference engineering maps the full migration path from a synchronous loop to a batch worker.
Serving-side levers compound with placement. Prompt caching removes redundant prefill work when many requests share a stable prefix, quantization trades a small quality margin for materially cheaper GPU-hours, and autoscaling against request depth keeps reserved capacity from idling overnight. None of these require re-architecting an application; they require measuring cost per successful request before and after each change, which is the only metric that keeps optimization honest.
EU Rules Now Bind Deployments
Compliance now has dates attached. The AI Act entered into force on 1 August 2024 and reaches its general application date on 2 August 2026. The Commission’s AI Act overview sets out a risk-based framework with four levels, from prohibited practices to minimal risk, with obligations for general-purpose model providers that already apply separately from the general date. For cloud teams the practical consequence is documentation discipline: knowing which model powers which feature, what data trained or fine-tuned it, and who is the provider versus the deployer in each integration.
Most teams using hosted model APIs fall on the deployer side of the line, which carries lighter duties but not zero: purpose limitation, human oversight for consequential decisions, and logging sufficient to reconstruct what a system did and why. Teams fine-tuning models for their own verticals should assume provider-adjacent documentation expectations, because the boundary turns on how the model is placed on the market rather than on who trained the base weights.
Baseline cloud adoption shapes both vendor strategy and capacity planning. The Eurostat enterprise cloud statistics show most enterprise buyers use paid cloud for e-mail, office software and file storage, which means AI features are typically layered onto existing cloud estates rather than greenfield builds. Multi-region egress, data residency preferences and existing enterprise agreements therefore constrain placement as much as hourly GPU prices do.
Portugal Deployment Checklist
Work the checklist in order; each step either moves spend to a cheaper tier or removes a compliance unknown.
- Classify every workload as interactive, asynchronous or fault-tolerant training, and record its latency budget and blast radius.
- Route interactive requests to provider APIs with prompt caching enabled where prefixes repeat, and pin model versions per feature.
- Move asynchronous bulk jobs to batch endpoints, with idempotency keys, per-batch manifests and scheduled retrieval instead of blocking waits.
- Place fault-tolerant training on spot capacity behind a queue, with checkpoint intervals measured in minutes and resumable data loaders verified by restore drills.
- Map AI Act touchpoints per feature: provider or deployer role, risk tier, human oversight points and retention of logs and prompts.
- Tag cloud spend per model and per tenant, and report cost per successful request monthly so regressions surface before the invoice does.
Teams that finish the checklist end up with a portfolio: APIs where speed of iteration wins, managed platforms where control matters, and spot where cost discipline pays. That portfolio, revisited quarterly against vendor price changes and regulatory guidance, is what keeps cloud AI spend proportionate to the value each workload returns.