Leadership · PiniShv

Zuckerberg Is Building an AI CEO Assistant. The Rest of Us Should Have Started Already.

Mon, 23 Mar 2026 10:00:00 +0200

The news
#

Mark Zuckerberg is reportedly building an AI agent to help with his CEO duties, according to The Wall Street Journal. The agent is in training and already retrieves answers that would normally require coordination across multiple teams. Meta is also building an internal tool called “Second Brain” that searches and organizes company documents and project data.

Meanwhile, Anthropic’s Dario Amodei is calling AI a “general labour substitute.” Sundar Pichai said AI could replace him within a year. Sam Altman said AI will “do my job better.”

CEOs of AI companies are telling you that AI can do CEO work. And now the CEO of one of the largest companies on the planet is building exactly that.

My take
#

My honest reaction: this feels late.

I’ve been running two AI assistants for a while now. One for personal life, one for work. They’re not products I bought. They’re systems I built and keep building. They’re always a work in progress.

The way it works is simple. Every time I run into a new challenge, a new type of decision, a new workflow that keeps repeating, I don’t just solve it once. I teach the assistant how to handle it next time. I update the instructions, add context, refine the approach. The assistant gets better not because the model improved, but because I gave it better structure.

Over time, the assistant becomes a reflection of how I think about recurring problems. Not a replacement for my judgment. An amplifier of it. It handles the retrieval, the first-pass analysis, the pattern matching across things I’ve already decided before. I handle the exceptions, the judgment calls, the things that actually need me.

This isn’t exotic. The tools are available to everyone. Claude, ChatGPT, custom GPTs, MCP connections to your actual systems. The barrier isn’t technology. It’s the habit of investing fifteen minutes every time you solve something to make sure the assistant can handle similar situations going forward.

That’s what Zuckerberg is doing. He’s just doing it with a team of engineers instead of on his own.

Why this matters beyond CEOs
#

The framing in the news is “AI CEO assistant.” That makes it sound like an executive luxury. It’s not.

Every knowledge worker who makes decisions, coordinates across teams, retrieves information from multiple sources, and handles recurring workflows is doing work that an AI assistant can partially absorb. Not replace. Absorb. The routine retrieval, the context gathering, the first draft of a decision framework.

The people who build these systems early compound the advantage over time. Every week the assistant gets a little smarter about your specific context. Every month the gap between “using AI occasionally” and “having an AI system that knows how you work” gets wider.

Zuckerberg making news for building this tells me most people haven’t started. And that’s the real story. Not that the CEO of Meta is doing it. That most people aren’t, when they easily could be.

If you’re waiting for someone to build the perfect AI assistant product for you, you’ll be waiting a long time. The best version is the one you build yourself, iteratively, by teaching it how you actually work.

Start today. It doesn’t need to be good on day one. It needs to exist. You’ll make it better every week.

Building your own AI assistant system? I’d love to hear how you’re approaching it. Find me on X or Telegram.

Krakow Offsite: Real Connections, Real Momentum

Thu, 23 Oct 2025 00:00:00 +0000

Originally published on LinkedIn: Read the original article

Ben Gurion Airport, 2:30 am Monday
#

We kicked off in the small hours between Sunday and Monday and touched down in Krakow at 9:00 am.

From Israel, a group of managers joined me to spend focused time with our colleagues based across Poland, together with our partners at Trust Offshore Talent Sourcing.

Krakow was our hub for the week, a central place to meet. I was warned it would be freezing, yet the weather was pleasantly mild. Great food, kind people, clean and beautiful streets. Highly recommended.

Krakow is a gem

The Week That Was
#

Our days were intentionally intense: work sessions, 1:1s, whiteboards, shared meals, city walks, and a cooking workshop. Evenings continued the conversations, built trust, and yes, included a little shopping. The goal was simple: maximize time together with our colleagues and with one another.

This was my first in-person meeting with my team since I hired them almost three years ago. Sitting side by side helped us gel as a team, pressure test our strategy, spark ideas, and have the kind of deep debates that only happen in the same room. We left with shared context, sharper priorities, clear owners, and concrete next steps.

Meeting teammates from across Poland also helped me understand their needs far better and share my perspective, which matters a lot given the cross-functional nature of my role. I am confident our productivity and collaboration will grow from here.

The People
#

I came away impressed, person by person, with the caliber of our people in Poland. That does not happen by accident. It reflects thoughtful hiring by our managers, sharp judgment by interviewers who know how to spot the signal, and strong partnership from HR keeping the bar high.

I also got to know the other managers on the trip much better. Sharing long days, tradeoffs, and decisions gave me a clearer view of how each of us thinks and leads. That stronger bond will show up in how we collaborate, how quickly we align, and how we support our teams.

Ben Gurion Airport, 6:30 am Friday, finally well-deserved rest
#

Thank You
#

To Stampli’s leadership team for initiating and enabling this. Your push made it possible and meaningful.
To our partners at Trust Offshore Talent Sourcing for orchestrating the week end to end with professionalism and care.
To our teammates across Poland for the hospitality, candor, and craftsmanship. You made the time count.
To my fellow managers for the shared leadership, open conversations, and momentum we are carrying home.
And to everyone involved for your energy, ownership, and the quality of thinking you brought into every room.
A special thanks to Stampli for making all of this possible and bringing these incredible people into the same room.

Let’s keep the pace, turn this energy into execution, and find more moments to connect in person where it makes sense.

– Pini

Want to connect? Find me on LinkedIn or check out more of my articles and insights.

AI Security Isn't a Tool Problem, It's a Culture Problem

Tue, 14 Oct 2025 00:00:00 +0000

This is the final part of the “Securing Intelligence” series on AI security.

Over this series, we’ve covered the technical landscape of AI security: prompt injection attacks, defensive architectures, and supply chain vulnerabilities. We’ve talked about AI firewalls, zero-trust principles, model verification, and monitoring systems.

All of it is necessary. None of it is sufficient.

The reality is clear: the organizations that get breached aren’t the ones with the worst technology. They’re the ones with the worst culture.

They’re the teams where developers ship AI features without security review because “it’s just a chatbot.” Where someone downloads an untrusted model because “everyone uses it.” Where security concerns are dismissed as “slowing down innovation.” Where AI is treated as fundamentally different from software, exempt from the practices that keep everything else secure.

The final piece of AI security isn’t a tool or architecture—it’s building an organization where security is everyone’s responsibility and every AI deployment is treated with appropriate caution.

Let me show you what that actually looks like.

Why AI Security Is Different (And Why That Matters)
#

Traditional security has decades of established practices. Developers know not to trust user input. Security teams know how to review code. Everyone understands concepts like least privilege and defense in depth.

AI security breaks most of these mental models.

You can’t just sanitize inputs—natural language is too flexible. You can’t easily audit code—the “logic” is encoded in billions of parameters. You can’t predict all behaviors—emergent capabilities mean models can do things they weren’t explicitly trained for.

This creates a dangerous dynamic: traditional security teams don’t fully understand AI risks, and AI teams don’t fully understand security practices. Each side speaks a different language, and the gaps between them are where vulnerabilities hide.

Organizations that succeed bridge this gap. They build shared understanding, shared vocabulary, and shared responsibility for AI security. The ones that fail maintain silos and wonder why their sophisticated technical controls keep failing.

Security as Part of the AI Development Lifecycle
#

Most organizations treat security as a gate at the end of development. You build the AI feature, then you ask security to review it, and they either approve or send you back to fix things.

This doesn’t work for AI systems. By the time your chatbot reaches security review, you’ve already chosen your model, structured your prompts, defined tool permissions, and built your data pipelines. If any of those fundamental choices are insecure, you’re not going to fix them with a few tweaks—you’re rebuilding from scratch.

Security needs to be present from the first design conversation:

At the ideation stage: “What data will this AI need? What actions should it be able to take? What’s the worst-case scenario if it’s compromised?”

During architecture: “How do we separate trusted and untrusted data? What isolation boundaries make sense? Where do we need human approval?”

In implementation: “Are we using structured prompts? Have we limited tool permissions? Are we logging enough for incident response?”

Before deployment: “Have we red-teamed this? What monitoring is in place? What’s our rollback plan if behavior changes unexpectedly?”

Post-deployment: “What patterns are we seeing? Are there anomalies? What can we learn for the next system?”

This isn’t “security slowing down innovation.” This is preventing the catastrophically expensive security incident that really slows down innovation.

Building Effective Cross-Functional Collaboration
#

The typical dynamic I see: AI/ML engineers want to move fast and experiment. Security teams want thorough review and established patterns. Product teams want features shipped. Legal wants liability limited. Everyone’s optimizing for different goals, and AI projects get caught in the middle.

Organizations that make this work do a few things differently:

They Create Shared Incentives
#

Don’t make security and velocity opposing forces. Make security incidents everyone’s problem. When an AI system gets compromised, it shouldn’t just be security’s failure—it should impact team bonuses, project timelines, and career advancement.

Conversely, when teams ship secure AI systems on schedule, celebrate it. Make “secure by default” a point of pride, not an obligation.

They Establish Security Champions
#

Embed security expertise in AI teams. Not full-time security engineers, but developers who’ve been trained in AI security and can make basic security decisions without waiting for review.

These champions become translators—they understand both AI technology and security requirements, and they can bridge conversations that would otherwise deadlock.

They Run Joint War Games
#

Quarterly exercises where developers, security, and product teams work together to red-team AI systems. Not as adversaries, but as collaborators trying to find weaknesses before attackers do.

This builds empathy and understanding. Developers see how creative attackers are. Security teams understand the constraints developers face. Everyone learns.

They Make Security Visible
#

Create dashboards that show AI security metrics alongside product metrics. How many AI systems have we deployed? How many have been security-reviewed? What’s our average time-to-detect anomalies? How many supply chain components have we vetted?

When security is visible, it becomes real. When it’s hidden in compliance documents, it gets ignored.

Training Teams to Think Adversarially
#

Most developers are optimists. They build features assuming users will use them as intended. This is fine for traditional software with well-defined interfaces. It’s dangerous for AI systems with natural language interfaces and emergent behaviors.

AI teams need to think like attackers. Not occasionally during security review, but constantly during development.

What this looks like in practice:

Design reviews ask: “If I wanted to break this system, what would I try? If I wanted to extract sensitive data, where would I look? If I wanted to influence behavior, what would I inject?”

Code reviews check: “Is this mixing trusted and untrusted data? Does this give the AI more permissions than it needs? What happens if the model outputs something unexpected?”

Testing includes adversarial cases: Don’t just test happy paths. Test injection attempts. Test edge cases. Test unusual input combinations. Test what happens when external dependencies are compromised.

This mindset shift is cultural, not technical. It’s about building teams that instinctively question assumptions and think about what could go wrong, not just what should go right.

Creating Accountability Without Killing Innovation
#

Here’s the tension every organization faces: you want teams to experiment with AI and move quickly, but you also want them to do it securely. Push too hard on security, and innovation slows to a crawl. Push too hard on velocity, and you ship vulnerable systems.

The organizations getting this right use graduated controls:

Low-Risk AI Systems: Fast Lane
#

Internal tools with limited data access and no customer impact? Lightweight security review. Automated checks for common issues. Fast approval.

The trade-off: if it breaks, the blast radius is small.

Medium-Risk AI Systems: Standard Process
#

Customer-facing features, moderate data access? Standard security review. Documented architecture. Anomaly monitoring. Human approval for high-stakes actions.

High-Risk AI Systems: Rigorous Process
#

Systems with access to PII, financial transactions, healthcare data, or code execution in production? Comprehensive security review. Red teaming. Extensive monitoring. Incident response plans. Regular audits.

The key is that everyone understands the categories and why they exist. Security isn’t arbitrary gatekeeping—it’s proportional response to real risk.

The Metrics That Actually Matter
#

Most organizations measure the wrong things. They count how many security reviews they’ve completed or how many vulnerabilities they’ve found. These are vanity metrics that don’t tell you if you’re actually secure.

Better metrics focus on outcomes:

Mean time to detect anomalies: When AI behavior changes unexpectedly, how quickly do you notice? If it’s days or weeks, you’re not monitoring effectively.
Percentage of AI systems with documented security posture: Do you actually know what data each AI system can access, what actions it can take, and who’s responsible for it?
Security incidents per AI deployment: Are you learning from incidents and improving, or are you repeating the same mistakes?
Supply chain verification coverage: What percentage of your AI components (models, plugins, datasets) have been vetted?
Time from security concern to resolution: When someone raises a security issue, how long until it’s addressed? If it’s weeks, security isn’t being taken seriously.
Developers trained in AI security: What percentage of your AI team has formal security training? If it’s under 50%, that’s a problem.

These metrics tell you whether your culture actually supports security or just pays lip service to it.

When Things Go Wrong: Incident Response for AI
#

Traditional incident response assumes you can analyze logs, identify the attack vector, and patch the vulnerability. AI incidents are messier.

How do you investigate an AI system that started behaving oddly? The “vulnerability” might be a poisoned model weight. The attack vector might be a document added to your RAG system six months ago. The attacker might be long gone, and you’re just now seeing the effects.

Organizations need AI-specific incident response playbooks:

Detection: What anomalies triggered the alert? Unusual outputs, unexpected data access, performance changes?

Containment: How do you limit damage without destroying evidence? Can you roll back to a known-good state?

Investigation: What changed recently? New model deployment, updated data sources, modified prompts, external dependency updates?

Remediation: Is this a prompt injection, model compromise, supply chain attack, or something else? The fix is different for each.

Post-mortem: What can we learn? How do we prevent this category of incident in the future?

The hardest part: AI systems evolve continuously. Your known-good baseline from last week might not be valid anymore because you fine-tuned the model or added new data. Incident response needs to account for this fluidity.

The Leadership Challenge
#

If you’re a VP of Engineering, CTO, or CISO, AI security ultimately comes down to decisions you make:

Do you allocate budget for security tools and training? If not, your teams can’t succeed no matter how much they care.

Do you slow down deployments when security concerns are raised? If not, you’re signaling that velocity matters more than security, and teams will internalize that.

Do you celebrate teams that catch security issues? Or only teams that ship features? What you reward is what you’ll get more of.

Do you have clear accountability for AI security? Or is it everyone’s responsibility and therefore no one’s?

Do you invest in the unglamorous work of monitoring, logging, and incident response? Or only the exciting work of new AI features?

These cultural choices matter more than any specific technical control. The best AI firewall in the world won’t save you if your culture treats security as optional.

What Success Actually Looks Like
#

I’ve worked with organizations that get this right. Here’s what I see:

Developers raise security concerns proactively. They don’t wait for security review—they think about attack vectors during design and flag potential issues early.

Security teams understand AI enough to be helpful. They don’t just say “this is risky” and walk away—they collaborate on solutions that work for both security and product needs.

Incidents are learning opportunities, not blame exercises. When something goes wrong, the focus is on systemic improvement, not punishment.

Security is visible and measured. Everyone knows the current state, the goals, and how they contribute.

Innovation happens quickly but safely. Teams ship AI features fast because security is built in from the start, not bolted on at the end.

There’s a healthy paranoia. Not fear that prevents action, but awareness that AI systems are powerful, potentially dangerous, and deserve respect.

The Bottom Line: Culture Eats Strategy for Breakfast
#

You can implement every technical control from this series—defensive architectures, supply chain verification, monitoring systems, AI firewalls—and still get breached if your culture doesn’t support security.

Conversely, teams with great security culture often succeed with imperfect tools because they’re constantly learning, improving, and treating security as everyone’s job.

The organizations that will thrive in the AI era aren’t the ones with the best technology. They’re the ones that build cultures where security and innovation coexist, where teams think adversarially by default, and where AI systems are deployed with appropriate caution.

The choice is yours: treat AI security as a compliance checkbox and hope for the best, or build it into your organizational DNA and sleep soundly.

Wrapping Up the Series
#

Over these four articles, we’ve journeyed from threat landscape to technical defenses to supply chain risks to organizational culture.

The throughline: AI security is hard, perfect security is impossible, and success comes from building defense in depth—both technical and cultural.

If you take away one thing from this series, let it be this: your AI systems are powerful, useful, and potentially dangerous. Treat them accordingly. Build with security in mind from day one. Monitor continuously. Assume compromise and plan for it. And most importantly, create a culture where security is everyone’s responsibility.

The future belongs to organizations that can deploy AI safely at scale. Make sure yours is one of them.

Leadership · PiniShv

Zuckerberg Is Building an AI CEO Assistant. The Rest of Us Should Have Started Already.

The news #

My take #

Why this matters beyond CEOs #

Krakow Offsite: Real Connections, Real Momentum

Ben Gurion Airport, 2:30 am Monday #

The Week That Was #

The People #

Ben Gurion Airport, 6:30 am Friday, finally well-deserved rest #

Thank You #

AI Security Isn't a Tool Problem, It's a Culture Problem

Why AI Security Is Different (And Why That Matters) #

Security as Part of the AI Development Lifecycle #

Building Effective Cross-Functional Collaboration #

They Create Shared Incentives #

They Establish Security Champions #

They Run Joint War Games #

They Make Security Visible #

Training Teams to Think Adversarially #

Creating Accountability Without Killing Innovation #

Low-Risk AI Systems: Fast Lane #

Medium-Risk AI Systems: Standard Process #

High-Risk AI Systems: Rigorous Process #

The Metrics That Actually Matter #

When Things Go Wrong: Incident Response for AI #

The Leadership Challenge #

What Success Actually Looks Like #

The Bottom Line: Culture Eats Strategy for Breakfast #

Wrapping Up the Series #