Pierre Medina

Valencia, Spain / EU & remote opportunities

AI / ML ENGINEER · MLOPS · CLOUD SYSTEMS

Building AI systems
that work beyond
the demo.

I connect machine learning, software engineering and cloud infrastructure to build practical, observable and reliable solutions — from intelligent APIs to industrial energy systems.

Explore my work Get in touch
GitHub LinkedIn Email

01 / ABOUT

Engineering at the intersection of AI and real-world systems.

I'm Pierre, an engineer with a background in electrical engineering and industrial automation, now focused on applied AI, data platforms and cloud-native software.

My experience spans machine learning workflows, generative AI applications, API development and energy systems. That combination helps me approach technical decisions through both a software and an operational lens.

I value reproducible engineering, transparent trade-offs, thoughtful documentation and systems that are maintainable after the first release.

LOCATIONValencia, Spain
FOCUSAI · MLOps · Cloud
BACKGROUNDEngineering + Automation
LANGUAGESSpanish · English

02 / SELECTED WORK

Architecture-led.
Evidence-driven.

Selected open-source work and clearly labelled architecture explorations. I document the problem, design choices and verification plan rather than claiming unmeasured production results.

PROJECT / 01 Public MVP
MLOPS / BACKEND ENGINEERING

Enterprise MLOps
Platform

A reproducible reference implementation connecting model training, experiment tracking, automated testing and a prediction API — with synthetic data and no paid cloud dependency.

PythonMLflowFastAPIDockerGitHub Actions
View source code
ARCHITECTUREREFERENCE IMPLEMENTATION
  1. INPUTSynthetic dataReproducible dataset
  2. TRAINModel pipelineEvaluation + MLflow
  3. SERVEFastAPIValidated inference
  4. VERIFYCI / pytestAutomated checks
Engineering decisions

Context / problem. Demonstrate a complete, testable ML lifecycle without dependence on client data or paid infrastructure.

Role / scope. Public independent engineering implementation; no team size or production deployment claimed.

Trade-off. Chose local MLflow and synthetic data for portability over managed platform complexity.

Evidence. Public code, Docker setup, model training, API and CI tests. Not a production performance claim.

Next iteration. Add managed experiment storage, monitoring and a deployment environment once the baseline is verified.

PROJECT / 02Architecture in progress
INDUSTRIAL AI / ENERGY

Hybrid Energy
Intelligence

An energy dispatch architecture for solar PV, battery storage and diesel/gas backup generation under changing demand and uncertainty.

ForecastingBESSOptimizationCloud
SYSTEM DESIGNPROPOSED
  1. PV + demand
  2. AI forecast
  3. Dispatch
  4. BESS + gen
Design rationale

Problem. Balance cost, emissions and reliability with intermittent solar and backup generation.

Scope. Independent architecture study, not a live production system.

Decision. Separate forecast uncertainty from constrained optimization; compare against rule-based dispatch.

Planned validation. Cost and emissions deltas, unserved load and generator run hours on documented scenarios.

Open question. How to account for asset degradation and forecast error in dispatch?

PROJECT / 03Architecture concept
GENAI / API RELIABILITY

LLM Gateway
& Observability

A reference gateway design to centralize model-provider access, identity, budget limits, request tracing and graceful failure handling.

FastAPILLMsRate limitsTracing
SYSTEM DESIGNPROPOSED
  1. Clients
  2. Auth + limits
  3. Models
  4. Telemetry
Design rationale

Problem. Provider integrations become difficult to govern as consumption grows.

Scope. Proposed reference architecture; no production SLO claimed.

Decision. Centralized controls instead of policies duplicated across every application.

Planned validation. Latency, error rate, cost per request and fallback correctness.

Open question. Which routing strategy gives the best reliability/cost trade-off?

PROJECT / 04Architecture concept
DATA ENGINEERING / QUALITY

Reliable Data
Lakehouse

A maintainable data platform design with ingestion contracts, transformation layers, quality gates and operational monitoring.

DatabricksSQLData qualityCI/CD
SYSTEM DESIGNPROPOSED
  1. Sources
  2. Ingestion
  3. Quality gates
  4. Analytics
Design rationale

Problem. Downstream analytics lose trust when freshness and schema changes are invisible.

Scope. Proposed independent reference architecture.

Decision. Data contracts and automated quality gates over manual exception handling.

Planned validation. Freshness, completeness, failed pipeline recovery time and data-quality incident counts.

Open question. Where should strict contracts yield to schema evolution?

03 / EXPERTISE

The stack is a tool.
The outcome is the goal.

Technologies and domains I work with; no arbitrary skill percentages.

01

AI & machine learning

Python, scikit-learn, model evaluation, MLflow, feature engineering and explainability.

02

Generative AI & APIs

LLM applications, Gemini / Vertex AI, FastAPI, secure inference workflows and prompt evaluation.

03

Data & cloud platforms

GCP, Microsoft Fabric, Databricks, BigQuery, SQL, Docker, CI/CD and cloud-native integration.

04

Industrial systems

Energy analytics, solar PV, automation, monitoring, optimization and hybrid generation architectures.

04 / CONTACT

Let's build something
that matters.

Open to conversations about applied AI, MLOps, cloud engineering and technology opportunities in Spain or remotely.

Send an email pamedinaw@gmail.com