Ai Albert Platform Laravel Package

Product Decisions This Supports

• AI feature roadmap sequencing. The package is a Laravel-consumable bridge to the Albert platform (Étalab, France), which exposes OpenAI-compatible chat and embedding endpoints. That makes it a candidate enabling dependency for three roadmap items at once: conversational assistant features, semantic/vector search, and document-extraction pipelines — all without building a provider client from scratch.
• Build vs. buy for provider integration. The symfony/ai ecosystem already handles HTTP transport, capability negotiation, and—since v0.8.0—a provider abstraction and model routing layer. Buying into that abstraction (MIT-licensed) beats hand-rolling per-provider clients, but only if we accept symfony/ai as a foundational dependency in our stack.
• Vendor and hosting strategy. Enables an explicit "EU-sovereign AI" option in the roadmap: French-hosted inference under Étalab governance, OpenAI-compatible surface area. Useful for public-sector, health, legal, and any roadmap item where data-residency questions would otherwise stall procurement.
• Cost and lock-in posture. Model routing (v0.8.0) plus a shared provider interface lets us treat model choice as configuration, not architecture — a prerequisite for any credible "multi-provider / cost-optimized inference" decision later.
• Sustainability / ESG reporting for AI usage (new in v0.14.0). Inference results now carry Albert's carbon footprint as result metadata. This turns a vague "AI has an environmental cost" talking point into per-request data we can aggregate into usage dashboards, internal ESG reporting, or green-procurement responses. Treat it as a reporting hook, not a control: it is only as decision-grade as Albert's methodology, and it does not by itself give us per-model carbon routing. But it is the first capability in this package that speaks to a non-engineering stakeholder (sustainability, procurement, public-tender compliance) without us building instrumentation ourselves.
• Scope decisions it does not support well. Fine-tuning, streaming-heavy UX, and provider-specific advanced features should not be planned on top of this package without an explicit spike; the README points only to the Albert API reference and OpenGateLLM model compatibility docs. Carbon metadata does not yet mean carbon-aware routing — do not plan "route to the lowest-carbon model" on the strength of a metadata field.
• Use cases the package directly unlocks: chat assistants on EU-hosted open models; embeddings for Meilisearch/Postgres pgvector semantic search (embeddings capability landed in v0.4.0); queued batch summarization/classification; provider fallback (Albert primary, commercial API secondary) via the abstraction layer; AI usage-and-emissions reporting surfaced alongside cost reporting.

When to Consider This Package

Adopt when:

• Data residency, GDPR/DSGVO posture, or public-sector procurement makes an EU-hosted, OpenAI-compatible inference endpoint a requirement rather than a nice-to-have.
• You already run (or are willing to run) symfony/ai components inside Laravel — the service container and HTTP client are compatible, but this is a Symfony-first package, not a Laravel-first one.
• You need both chat completions and embeddings from one provider, and you want them behind a single interface so a fallback provider is a config change.
• You must report on AI environmental impact — CSRD-adjacent reporting, French/public-sector green-procurement criteria, or an internal sustainability commitment. v0.14.0's carbon-footprint metadata is a cheap, first-party source for that number; verify the methodology before it lands in an external report.
• Your team is comfortable reading Symfony docs and the Albert/OpenGateLLM API reference to fill documentation gaps.

Look elsewhere when:

• Track record matters. One star, zero dependents, and several releases marked "no significant changes" (v0.5.0–v0.7.0) mean this is early, thinly adopted infrastructure. The v0.14.0 bump is a routine minor plus one metadata feature — it does not change the maturity picture. Do not put it on a critical path without a fallback and a fork plan.
• You need proprietary frontier models (GPT-class, Claude) as the primary path — Albert's catalog is open-weight models; check the OpenGateLLM supported-models table before committing.
• You need streaming-first UX, fine-tuning, or provider-native tooling; verify against the Albert API reference, and expect to own the gap.
• Carbon reporting is a hard requirement with an audit trail — a metadata field from an early-stage package is not an assurance-grade emissions source. Validate methodology and completeness; if it fails, look for a dedicated measurement layer rather than bending this package.
• Your team is Laravel-only and allergic to Symfony abstractions — the integration cost lands on you, not the package.
• You need documented SLAs, rate-limit guarantees, or support contracts. None are evident here; quotas must be measured empirically before they appear in a commitment.

How to Pitch It (Stakeholders)

Executive summary. "There's a small open-source (MIT) bridge that lets our PHP/Laravel code talk to Albert — a French government-backed, OpenAI-compatible AI platform. In plain terms: we can ship AI features on EU-hosted models with the same integration effort as a commercial API, and swap providers later by changing configuration instead of rewriting code. As of v0.14.0 it also returns a carbon-footprint figure with each AI response, which is a low-cost way to start putting environmental reporting behind our AI features instead of hand-waving about it. It's strategically useful if we care about data residency, vendor leverage, or sustainability reporting; it is not yet a bet-the-roadmap dependency. Recommendation: time-boxed pilot on one non-critical feature, with a commercial-provider fallback wired in from day one."

For engineering. The bridge sits on symfony/ai and inherits its provider abstraction and model-routing layer (v0.8.0) plus embeddings capability (v0.4.0); v0.14.0 adds carbon-footprint values to response metadata. Concretely: register the provider in the Laravel container behind our own interface, keep the provider choice in config, drive embeddings into our existing vector store, and queue inference calls so latency doesn't hit request paths. Capture the carbon metadata at the same seam where we already capture tokens/latency into our observability pipeline — do not let it leak into domain objects. Three caveats to plan around — it's Symfony-first (expect glue code, not Eloquent-native ergonomics), the symfony/ai dependency pins PHP/version constraints we must verify against our current Laravel matrix, and carbon values are per-response metadata with no documented aggregation contract: confirm units, whether the value is null for some models, and whether it sums meaningfully across a queue of jobs. Mock at the HTTP boundary in tests; measure p50/p95 latency and rate-limit behavior in the pilot rather than trusting docs.

For compliance/legal. Albert is hosted in France under Étalab, which is the strongest argument for this package — it gives us a defensible data-residency story for regulated or public-sector work, without a proprietary vendor contract. The new carbon metadata is a secondary but real benefit: it supports green-procurement and ESG-style disclosures with first-party data rather than estimates. Mitigation: confirm Albert's logging/retention terms against our DPA requirements before launch, and keep the provider abstraction as the compliance seam so residency checks and future provider swaps live in one place. On carbon, treat the figures as informational until methodology is confirmed — do not cite them in an external or audited disclosure without sign-off.

Pilot exit criteria (what I'd ask for before scaling). Latency and error-rate benchmarks against our current provider; confirmed rate limits and quota headroom; embeddings quality validated on our own retrieval eval set; a working fallback path proven by test; carbon metadata validated for units, coverage across our chosen models, and aggregation into our reporting pipeline (or explicitly deferred); and a decision on whether we own the Symfony glue or wait for the ecosystem to mature.