Cloud Computing Köln - Seite 10 von 7053 - Neues zu Cloud Computing, Internet of Things und Technologien

First-of-its-kind telecom AI deployment

Telecommunications organizations are increasingly looking to AI to help teams navigate highly specialized domains, but generic models often lack the industry-specific knowledge needed to understand telecom networks, standards, and operations. To address that gap, AT&T created their Open Telco (OTel) models, the next generation of telecom-focused AI designed to bring deeper telecommunications expertise into AI systems. Building OTel2.0 required more than training a large language model, it reflected a broader issue many organizations face: how to build domain-specific AI systems at scale while balancing cost, performance, and operational complexity. Cost management quickly became a key consideration. To continue advancing telecom-focused AI, AT&T needed a platform capable of supporting OTel2.0 development at an entirely new scale.

Where teams previously had to own and manage deployments, infrastructure, and the associated operational overhead, Foundry Managed Compute provided a more streamlined way to access dedicated graphics processing unit (GPU) capacity. This transformation requires more than powerful models; it requires the ability to scale without compromising cost, flexibility, or performance.

Learn how OTel2.0 scales telecom AI

Using Microsoft Foundry Managed Compute, AT&T was able to experiment across multiple open models, optimize workloads across different GPU architectures, and process massive volumes of telecom data all within a unified platform. The result was an AI development environment capable of supporting trillions of tokens while giving teams the flexibility to iterate, optimize, and innovate faster.

Model choice meets infrastructure flexibility

Building OTel2.0 required flexibility across both models and infrastructure. Rather than standardizing on a single model, AT&T adopted a multi open-model strategy. Open models were central to AT&T’s approach because they provided the flexibility to work with approved telecom data, tailor the workflow for domain-specific model development, and support large-scale experimentation with greater control over cost and deployment strategy. Through Microsoft Foundry, the team deployed several models from the Hugging Face collection, including Phi-4, OSS-120B, and Gemma-4, to support different stages of development, from synthetic data generation and data preparation to reasoning-intensive workloads and broader model development efforts. Phi-4 played a significant role in this process, processing more than 700 billion tokens a month as part of the broader data preparation and training workflow for OTel2.0.

Every company in the world needs to build its own AI, and that is only possible with open models and open source. AT&T is championing this vision, building on open models like Phi-4 and Gemma, and giving OTel back to the community as a telecom AI foundation others can build upon. Microsoft Foundry makes this practical at scale, bringing the latest open models from the Hugging Face collection together with AMD and NVIDIA GPUs in one place, so teams can pick the right model and the right hardware, then deploy in hours instead of weeks.
—Jeff Boudier, Vice President of Product, Hugging Face

Developing OTel2.0 also required infrastructure capable of operating at telecom scale. AT&T used approximately 530 GPUs through Microsoft Foundry Managed Compute spanning multiple GPU architectures including 430 AMD Instinct™ MI300X GPUs. This heterogenous approach gave AT&T more flexibility in how models were deployed and optimized as requirements evolved.

ModelExample workloadPhi-4Around 700B tokens a month for data preparation and synthetic data generationOSS 120BHigher-reasoning workloads Gemma 4OTel2.0 development workflowsTable 1: Explains what open source models were used and how

This flexibility illustrates a broader trend across AI development. Organizations increasingly need platforms that allow them to choose the right model for the job, optimize for cost and performance, and scale workloads without rebuilding operational environments. Microsoft Foundry brings model choice, infrastructure flexibility, governance, and operational scale together in a unified platform that supports those requirements.

Start building with Microsoft Foundry

Beyond flexibility and cost, deployment speed is a critical factor for many AI initiatives. As workloads expand and new models are evaluated, the ability to access GPU capacity quickly enables teams to move from experimentation to execution faster without lengthy provisioning cycles. With Foundry Managed Compute, AT&T could deploy and scale models in days rather than waiting weeks for infrastructure to become available, helping accelerate development timelines and maintain momentum across OTel2.0 development.

Optimizing cost without limiting innovation

As AI workloads grow, economics become as important as model performance. For AT&T, one of the primary objectives was to lower AI model consumption costs while continuing to drive meaningful business value through AI-powered innovation. By using open models on Microsoft Foundry Managed Compute, AT&T was able to support large-scale data preparation and model development using a different economic model built around dedicated GPU infrastructure and open-model flexibility.

The impact became clear at scale. In support of OTel2.0, AT&T processed approximately 1T tokens, consisting of raw documents from GSMA supplemented by synthetic data generated. Generating the data using open-source models like Phi-4, served by Microsoft’s Foundry Managed Compute, saved tens of millions of dollars versus using frontier models. This allowed teams to invest in larger-scale experimentation and development while maintaining a focus on business value and operational efficiency.

MetricValueOTel 1.0 DownloadsOver 25MGPUs Used Through Foundry Managed ComputeAbout 530Tokens Processed for OTel2.0About 1TTokens Trained for OTel2.0About 400 BModels used to train OTelPhi-4, OSS 120B, Gemma 4Table 2: Quick facts about the OTel model family and metrics around what was used to build OTel2.0

When you are processing hundreds of billions of tokens, infrastructure becomes part of the problem you solve. Foundry Managed Compute gave us access to GPU capacity at scale so our teams could focus on advancing OTel2.0 instead of managing infrastructure.
—Mark Austin, Vice President, Data Science and AI at AT&T

At this scale, infrastructure is no longer simply a deployment consideration. It becomes a strategic component of AI development.

Accelerating the next wave of production-scale AI

OTel 2.0 demonstrates how organizations can combine open models, scalable infrastructure, and domain expertise to build production-ready AI systems. By matching different models to different workloads and optimizing infrastructure for cost and performance, AT&T was able to process trillions of tokens while maintaining operational efficiency.

As organizations move from AI experimentation to production deployment, they increasingly need the flexibility to choose the right models, optimize infrastructure, and scale efficiently. Microsoft Foundry and Foundry Managed Compute help support that transition by bringing those capabilities together in a unified platform.

Learn more

Read Scott Guthrie’s blog about Azure AI and HPC infrastructure.

Learn more about OTel2.0.

Explore session topics from AMD’s Advancing AI:

From GPUs to CPUs: Optimizing Every AI Workload with Azure and AMD

What’s Next for AI Infrastructure in the Cloud?

Powering the Future of AI on Azure

Discover how Microsoft and AMD are expanding Azure AI and HPC infrastructure.

The post AT&T and Microsoft scale trillion-token workloads with Microsoft Foundry and AMD appeared first on Microsoft Azure Blog.
Quelle: Azure

25. Juli 2026

da Agency

Agentic AI Needs Guardrails, Not Guesswork

What does it take to secure AI agents without slowing developers down? A recent panel explored the answer

I recently joined Zach Lloyd, founder and CEO of Warp; Gavriel Cohen, co-founder and CEO of NanoCo and creator of NanoClaw; and moderator Moriah Hara, founder of a community of more than 3,000 CISOs and a three-time Fortune 500 CISO, for a discussion on one of the biggest challenges facing enterprise security teams today: how to safely unlock the productivity of agentic AI.

The rapid rise of agentic AI in the enterprise is putting CISOs in a tough spot. On one hand, business leaders are clamoring to run with the new technology, which promises a productivity revolution like no other. On the other, setting AI agents loose without rigorous guardrails creates severe vulnerabilities.

Moriah put the dilemma facing CISOs like this: “The business wants AI agents everywhere, developers are already using them, sometimes without approval, oftentimes without security. …CISOs are left in this uncomfortable middle where we’re tolerating some tools, we’re praying that nothing breaks, we’re buying some time until we can get some governance beyond policy in place to have better visibility.”

The panel explored the role of the CISO in balancing this tension between productivity and security. Here are some highlights.

Isolate, control, observe

They came at it from different angles, but the panelists agreed on one imperative: running AI agents safely requires an isolated environment with trusted control boundaries. For Zach, Warp’s Oz platform provides that isolation. It’s a cloud agent infrastructure for secure and automated deployment of coding agents that allows centralized management, access controls, and visibility into what agents are doing across the organization.

Zach said you can “literally pull up the Oz web app and see what every agent across your company is doing at all times—which is a way better situation than the world we’re in right now, where someone on your marketing team is running Cloud Code, someone on your sales team is running Codex, and you just have no idea what’s going on, what tools they’re installing.”

NanoClaw—a personal AI agent

At Docker, our answer to the challenge of running AI agents safely is to run them in disposable, isolated, local sandboxes. Docker Sandboxes give agents the freedom and autonomy they need to do their best work, safely. Call it YOLO mode with guardrails. As Moriah noted in our discussion, agentic speed should be encouraged— “it’s the ungoverned speed that is the problem.” When agents are allowed to run fast without running wild, speed and safety are no longer a tradeoff.

Of note here: In March, we announced the integration of NanoClaw with Docker Sandboxes to deliver secure-by-design agent execution. The integration allows every NanoClaw agent to run inside a disposable, MicroVM-based Docker Sandbox that enforces strong operating system-level isolation. The stack takes advantage of NanoClaw’s minimal attack surface and fully auditable open-source codebase to meet enterprise security standards.

Laptops as the new prod

A key focus of the discussion was where to run agents safely. With vibe coding exploding, and agents and Claws (a new class of agents) already in production, the laptop today is the most powerful node in the enterprise. It’s also the most exposed. As a colleague of mine recently put it, laptop and agent environments are the new prod, and they need to be governed like prod.

Zach stressed the need to get agents off people’s laptops and desktops and into a controlled, cloud-based environment where CISOs can see what every agent across the company is doing at all times.

Portability—from laptop to cloud

My position is that, if you run agents in a sandbox, it doesn’t matter where the box sits. It could sit on a marketing or finance person’s laptop, or on a DevOps engineer or cloud admin’s machine. As long as the trust boundary is established and you know what’s getting piped in and out of it, you’re locked and loaded for rapid prototyping, experimentation, and innovation.

By the way, this view syncs with Docker’s vision, which has always been about portability. Our vision was never everything is local. We start in the local environment, then lift off into distributed environments, Kubernetes clusters, public clouds, whatever. It’s the same with agents. Eventually they’ll lift off, be decoupled from human operators, and be able to run fully autonomously wherever needed—always in the same portable environment.

When agents build the supply chain

The supply chain today is a revolving door for opportunistic attackers like TeamPCP and ShinyHunters who exploit transient dependencies and other vulnerabilities, often needing only a short window of time to filch credentials and information.

How are CISOs to combat these risks when AI agents themselves are pulling base images, choosing dependencies, and assembling code—autonomously and without human oversight? After all, in an autonomous supply chain, traditional methods of scanning and patching after building are no longer feasible.

Keeping humans in the loop

The panelists shared several best practices. Zach urged keeping humans in the loop for picking clean, secure dependencies, especially upstream libraries, and setting up blessed images for agents to choose from. Gavriel recommended setting a minimum release age of seven days for images and minimizing dependencies—even safe ones.

A training-wheels approach

Gavriel also suggested a training-wheels approach to experimenting with agents, starting out using unpermissioned data to build skills and avoid sensitive data issues. “Unlocking the value today is important,” he said, “but even more important is having people build the skills of working with agents, because what’s going to be coming in the coming months and years is going to totally exceed anything that we have today. So, it’s really about building the muscle memory, building the skills.”

Layer security to limit the blast radius

My take? Opportunistic attackers are simply exploiting an ecosystem that’s inherently flawed and broken and that unfortunately won’t get fixed within the next six to 12 months. Until then, developers should assume these attacks will continue and prepare for them by layering security to limit the blast radius. That means reducing privilege, reducing third-party access to their environment, and using immutable tags, digests, and SBOMs (Software Bill of Materials) to lock manifests and enable rapid detection of poisoned images. And, yes, outsourcing the risk to a trusted build environment like Docker that provides clean, hardened images so you’re starting from a clean foundation.

MCP—the new shadow IT?

The panelists rounded out the discussion with a focus on the security implications of using MCP in developer environments. MCP (Model Context Protocol) is a standard that allows LLMs to access external data and use tools, potentially making AI more powerful and reliable.

The consensus was that centralized, secure governance is crucial for productivity and risk management. Gavriel stressed the importance of proper version control, credential management, and a “golden repository” of verified tools. Zach advocated for centralized management to avoid individual tool dependencies and ensure minimal access.

Making it safe and easy to run MCP servers

And Docker? About a year ago, we introduced an open source MCP Gateway that serves as a chokepoint between agents and external tools. Routing every tool call through this enforcement point, where it can be authenticated, authorized, and logged before it reaches the external system, enables a wide range of agents to access trusted catalogs of MCP servers. While it’s not clear to me how long MCPs will remain useful, given the exponential speed with which AI is evolving, Docker MCP Gateway solves an important challenge today. Like Docker Sandboxes, it makes enforcement strict instead of advisory.

A once-in-a-generation opportunity—and challenge

Enabling dev environments to take advantage of agentic AI is a once-in-a-generation opportunity, and CISOs are accountable for making sure the rush to do so doesn’t devolve into the Wild West.

Moriah closed the panel with a provocative thought: “Six months from now, enterprises are all going to be running agents at scale. The one key success factor will be whether governance was present from day one or got bolted on after the first major incident.”

In the choose-your-own-adventure reality of agentic AI today, what kind of security leader will you be?

Quelle: https://blog.docker.com/feed/