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

标签:#Enterprise

找到 54 篇相关文章

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 原文 →
AI 资讯

Fika Jobs raises $4M to build a video-first hiring platform where AI agents interview candidates

The hiring process has long been criticized for its inefficiency and opacity. Candidates spend hours writing applications and submitting cover letters, only to disappear into what often feels like a black box. Generative AI has only made things messier, with employers increasingly relying on AI-powered screening systems to sift through an overwhelming number of submissions. […]

2026-06-23 原文 →
AI 资讯

Google Open Knowledge Format: Why Enterprise Agents Need a Knowledge Layer, Not Just More Tools

Google Open Knowledge Format: Why Enterprise Agents Need a Knowledge Layer, Not Just More Tools Most enterprise AI conversations still start in the wrong place. They start with the model. Which model should we use? Which framework should we adopt? Which vendor has the best agent platform? Which tools should we connect next? These are fair questions. But in real enterprise architecture, they are not the hardest questions. The harder question is this: Can our AI systems actually understand how our business works? That is why Google Cloud’s article on Open Knowledge Format caught my attention. The article talks about a simple but important idea: representing knowledge in a way that humans can read and machines can use. In OKF, that means markdown for the content and structured metadata for context. At first glance, that may sound too simple. But that simplicity is the point. Enterprises do not need another place where knowledge goes to die. We already have enough portals, catalogs, wikis, dashboards, folders, and internal tools. What we need is a practical way to package knowledge so it can be reviewed, versioned, governed, searched, and reused by both people and AI agents. That is where this idea becomes very relevant for agentic AI. The Real Enterprise AI Problem Most organizations already have the knowledge their AI agents need. They have it in databases, dashboards, tickets, architecture notes, runbooks, Confluence pages, data catalogs, code comments, incident reports, old project documents, and the heads of experienced employees. The issue is not that knowledge does not exist. The issue is that it is fragmented. Some of it is outdated. Some of it is duplicated. Some of it is tribal. Some of it is locked inside tools. Some of it is written for humans but not structured enough for AI systems to use reliably. This becomes a serious problem when we move from AI assistants to AI agents. An assistant can give a helpful answer. An agent does more. It plans, selects tools

2026-06-18 原文 →