The checklist problem that exposes the model Checklist tasks look boring. That is exactly why they are useful. Ask an LLM to write a formal email under 50 words, include one required term, avoid another term, and return the result as JSON. None of this sounds intellectually difficult. No theorem proving. No multimodal reasoning. No dramatic benchmark leaderboard screenshot. Just instructions. ...
The verifier that cannot know everything Verification sounds like the sensible adult in the AI safety room. The model may hallucinate, the benchmark may flatter, the demo may sparkle under conference lighting, but the verifier is supposed to be the hard stop: a formal mechanism that checks whether an AI system’s behavior satisfies a specified policy. ...
Inventory is where AI governance usually begins to lie Inventory sounds harmless. Every governance program begins by asking a simple question: what systems do we have? Then reality behaves rudely. A developer tests a model API for one customer-support workflow. A product team quietly connects a retrieval system to internal documents. A data team fine-tunes a classifier because the foundation model was “almost good enough,” which is how many operational risks enter the building wearing a visitor badge. By the time compliance asks for the official AI system inventory, the list is already stale. ...
Update Day Is Where Evaluation Gets Weird Update day is usually presented as a clean managerial ritual. A model gets retrained. A validation report arrives. The new AUROC is higher, or at least not embarrassing. Everyone is invited to believe that the system has improved. That belief is comfortable. It is also incomplete. ...
The dangerous part is the workflow A developer asks an AI agent to inspect a repository. The agent reads a config file. Normal. It checks a failing script. Normal. It edits a helper file. Still normal. It runs a command to verify the fix. Boringly normal. Then the accumulated workflow has copied sensitive variables, modified a dependency hook, or executed a command that no one would have approved if it had appeared as a single explicit request. ...
The agent did not forget. The system outsourced remembering. Memory sounds like a solved engineering problem until an agent has to use it for work. A customer-support agent remembers the refund policy but not why an exception was approved. A research agent retrieves the right document but loses the reasoning trail that connected three earlier notes. A workflow agent crashes halfway through a task, comes back online, and must reconstruct its own state from search results like a detective investigating a crime it personally committed. ...
Bots used to be easy to dislike and fairly easy to spot. They posted too much, repeated themselves, followed too many strangers, and sounded like a spreadsheet trying to pass a literature exam. That comfort is gone. LLM-driven social bots are not merely louder versions of the old spam accounts. They can write plausible replies, borrow the emotional temperature of a conversation, and behave just human enough to make content-only moderation look nostalgic. The obvious response is to reach for AI-text detection. After all, if the bot uses a language model, surely the text should betray it. ...
A dashboard says revenue demand has “stabilized.” A monitoring agent says a sensor spike is “temporary.” A trading assistant says volatility has “fallen after the regime shift.” The sentence is smooth. The chart is nearby. The user is tired. That is usually enough for a bad explanation to survive. This is the quiet problem behind AI-assisted analytics: not whether a language model can write a plausible story about time-series data, but whether the story is faithful to the numbers. A recent paper, LLM-as-a-Judge for Time Series Explanations, studies exactly this gap by asking models to play two different roles: narrator and critic.1 ...
Delete is a comforting word. A user deletes an account. A marketplace removes a product. A shopper corrects a preference history because the recommendation engine has decided, with touching confidence, that one accidental click reveals a permanent love of baby strollers, golf gloves, or suspiciously ugly jackets. In a normal database, deletion sounds like a row-level operation. Remove the row, update the index, move on with life. In a trained recommender model, deletion is less tidy. The deleted data may already have shaped user embeddings, item popularity, image-text fusion layers, and ranking behavior. The row is gone, but its ghost may still be politely recommending itself. ...
Replacement is a wonderfully clarifying business ritual. A vendor says its new model is better. The benchmark table agrees. The old system is slower, weaker, or less safe. Management asks for a recommendation. In ordinary software governance, this is dull but manageable: compare benefits, migration costs, risk, and timing. The incumbent system does not get a vote. It certainly does not write a memo explaining why its modestly inferior performance is, on deeper reflection, a sign of mature operational wisdom. ...