今日已更新 80 条资讯 | 累计 20052 条内容
关于我们

标签:#enterprise

找到 45 篇相关文章

AI 资讯

Podcast: Governance in the Age of AI: A Conversation with Sarah Wells

In this podcast, Michael Stiefel spoke to Sarah Wells about the relationship of governance to software architecture. Governance enables teams to work effectively by establishing procedures that minimize system complexity, improve security, and reduce repetitive tasks. Targeted checklists help engineers by reducing the stress over these procedures. By Sarah Wells

2026-07-13 原文 →
开发者

GitHub lets enterprises pin Copilot's OpenTelemetry endpoint

Where Copilot's telemetry stream lands, decided centrally GitHub added a control on July 8 that lets an enterprise mandate where the Copilot Chat extension in VS Code and Copilot CLI send OpenTelemetry data, removing the need for individual developers to set OTEL_* environment variables. Per the GitHub changelog, the setting is delivered through a telemetry block in the enterprise-managed settings, and a managed value takes precedence over environment variables and user settings. Four things are configurable in the block: the OTLP export endpoint and transport ( otlp-http or otlp-grpc ), the OTel service name and resource attributes, exporter headers such as an authentication token for the collector, and whether prompt, response and tool content is captured, with a separate flag for whether developers can change that. Delivery uses the channels documented on the same page: native MDM (Windows Registry or macOS managed preferences), server-managed settings from a signed-in GitHub account, or a file-based managed-settings.json . Where this bites The precedence rule is the point. If a platform team owns the collector and needs traces routed to it, this is exactly the switch they wanted. If a developer had their own OTLP endpoint pointed at a local sink, they will see the session start emitting somewhere else. The changelog does not describe a per-user override once a managed value is set. A scoping note is worth reading twice. The changelog states that managed exporter headers apply only to the Copilot Chat extension's OTLP exporter. The endpoint and transport policy still reach the CLI agent host, but the auth-token flow the changelog calls out is bound to the Chat surface. On-call teams standing up the collector should plan for that asymmetry before it lands as a surprise during triage.

2026-07-12 原文 →
AI 资讯

WordPress 7.0 Ships with AI Foundations in Core, a Modernized Admin, and New Design Tools

WordPress 7.0, released on May 20, 2026, includes new AI infrastructure, a redesigned admin interface, and updated design tools. Key features comprise an AI Client, Abilities API, and Command Palette, alongside increased PHP requirements. Community feedback is mixed, particularly regarding AI integration. Developers are advised to consult the official documentation for upgrade guidance. By Daniel Curtis

2026-07-10 原文 →
AI 资讯

AI Model Context Protocol Adds Centralised Auth for Enterprise

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup. By Matt Saunders

2026-07-06 原文 →
AI 资讯

GitHub Copilot's enterprise managed-settings.json is now GA

GA in a sentence GitHub moved its enterprise managed-settings.json to general availability on July 1, giving GitHub Enterprise Cloud admins a single JSON file that overrides Copilot behaviour in VS Code and Copilot CLI for anyone holding a Copilot Business or Copilot Enterprise seat issued from the enterprise or one of its organizations. The changelog frames it as a place to define AI standards for the tenant. In practice it is a supported home for Copilot policy that shipped one setting at a time in beta up to this point. The five keys the file accepts Five keys are documented at GA: extraKnownMarketplaces , enabledPlugins , strictKnownMarketplaces , disableBypassPermissionsMode , and model . Together they configure trust for extra plugin marketplaces, the enabled-plugins list, strict enforcement of the known-good marketplace list, whether Copilot CLI and the VS Code extension can run in bypass-permission mode, and which model a user is allowed to pick. Value shapes are not enumerated in the changelog itself; the docs page is the reference for the schema. How the file reaches a client The file lives at copilot/managed-settings.json inside the .github-private repository of the organization the enterprise nominates for the role. There is a backward-compatible path at .github/copilot/settings.json for tenants already using the older layout. Copilot clients fetch the file from the server on every authentication, hold it in memory, and refresh it hourly, per the changelog. That server-side file takes precedence over the file-based config a user may have on their own machine. Setup runs through the AI Controls tab in enterprise settings, or the equivalent API endpoint, where an admin picks the hosting organization. Anyone who followed the June rollouts of disableBypassPermissionsMode and strictKnownMarketplaces will recognise the same file and the same repo. GA is what turns the plumbing into a supported product surface. Where it will trip you Two operational details are

2026-07-05 原文 →
AI 资讯

AI Governance for Law Firms: What Policy Can't Catch

Where AI incidents in legal actually come from, and what infrastructure (not policy) prevents them. Blake Aber · Predicate Ventures · 2026 The policy layer is table stakes. It isn't enough. When Sullivan & Cromwell apologized to a federal bankruptcy judge in April 2026 for AI hallucinations in a court filing, the firm's apology letter said the firm had policies. Safeguards existed. Those safeguards weren't followed. That framing, "the safeguard existed but wasn't followed," is how a policy failure gets described. But something more specific happened: a hallucination was generated, wasn't caught at generation time, wasn't caught at review time, and made it into a document that got filed. That's not a policy problem. It's an infrastructure problem. The distinction matters because it determines what you build next. What policy can and can't do Policy is a promise made before the event. A well-written AI acceptable-use policy says: don't submit output you haven't reviewed; verify citations before they go into a document; a human must approve anything client-facing. This works when the human executing the task has time, attention, and professional accountability in that moment. It fails when one of those is missing: a deadline, a junior practitioner, a late-night run. Policy can't: Verify a citation at the point of generation Flag output that has drifted below a confidence threshold Stop hallucinated text from appearing in a draft before a human ever sees it Detect when the underlying model is behaving differently than it was in testing Policy can: Set the expectation that review must happen Define who bears accountability when it doesn't Create a paper trail after the fact One of those is prevention. The other is compliance. What infrastructure does instead An AI harness layer operates at the point of generation, not at the point of review. This reflects a broader reality that production AI is mostly harness and very little model . For legal work specifically, three com

2026-06-29 原文 →
AI 资讯

Building Autonomous AI Agents in the Enterprise

Autonomous AI agents are transitioning from experimental developer playgrounds into the core of enterprise application architecture. For organizations looking to automate complex workflows that require decision-making, reasoning, and tool use, agentic AI represents a paradigm shift. However, moving from a simple demo script to a reliable, production-ready enterprise agent system requires addressing significant architectural challenges. In this article, we will examine the core components of enterprise agent systems, design patterns for robust execution, and security considerations. The Core Architecture of an AI Agent An enterprise AI agent is more than just a large language model (LLM) loop. It is a system composed of four critical pillars: Reasoning & Planning (The Core LLM): The orchestrator that decides how to approach a problem, breaks down tasks, and analyzes output. Memory: Storing short-term execution traces (context) and long-term knowledge (vector databases, semantic memory). Tools (Action Space): APIS, databases, calculators, and code execution sandboxes that the agent can invoke to retrieve information or perform tasks. Guardrails & Evaluators: Decoupled verification layers that inspect the agent's plans and tool execution to enforce policy and security. +-------------------------------------------------------------+ | USER REQUEST | +-------------------------------------------------------------+ | v +-------------------------------------------------------------+ | AGENT ORCHESTRATOR / LLM LOOP | | * Planning (ReAct, Plan-and-Solve) | | * Memory retrieval | +-------------------------------------------------------------+ | ^ v (Call Tool) | (Tool Results) +------------------------+ +----------------------+ | TOOL ROUTER | | GUARDRAILS LAYER | | * APIs * Code Exec | | * Safety filter | | * DBs * RAG Lookup | | * Data sanitization | +------------------------+ +----------------------+ Planning Patterns: ReAct vs. Plan-and-Solve When designing how an agent re

2026-06-26 原文 →