Akshay Sharma

Akshay Sharma

Lead Member of Technical Staff, Salesforce | Data & AI Platforms | IEEE Senior Member

Chicago, Illinois, United States

Actions

Akshay Sharma is a Lead Member of Technical Staff at Salesforce, where he works on customer data graphs. He has spent more than 15 years building data and AI platforms for financial services, retail, and healthcare, including principal engineering roles at Capital One and Discover Financial Services, where he designed domain-driven medallion architectures and led legacy ETL modernization.

His recent work asks a practical question: what happens when AI agents and LLMs touch production data? He has built open benchmarks on LLM-driven pipeline repair, legacy ETL translation, bank-statement verification, and governed knowledge-graph retrieval, all released with code. His research is published in IET Software, and he reviews for IEEE Access and IEEE IT Professional.

Akshay has spoken at Dreamforce and The Economist, judged hackathons including LA Hacks and RevolutionUC, and is an invited keynote speaker at TAIMMA 2027. He is an IEEE Senior Member and a Member of the IET.

Area of Expertise

  • Finance & Banking
  • Information & Communications Technology
  • Travel & Tourism

Topics

  • Generative AI
  • LLMs
  • Multi-AI Agent
  • Knowledge Graphs
  • Retrieval-Augmented Generation (RAG)
  • Fintech
  • Data Engineering
  • Artificial Intelligence
  • The Future of AI in Software Engineering
  • Databases
  • Database
  • Snowflake
  • Machine Learning & AI
  • Claude
  • Turning AI Skills into Revenue
  • Data Security
  • Data Governance
  • Data Quality & Testing
  • Data Quality Monitoring
  • Software Engineering
  • Data Architecture
  • Software Architecture

Your Graph RAG Just Showed the Wrong Person the Wrong Data

Graph RAG systems decide what to retrieve by looking at the shape of the graph. Enterprises decide who may see what by ownership and role. These two boundaries rarely line up. In a bank’s customer graph, the densest clusters form around households, and each one mixes payments, lending, risk and support data. Retrieve by community and your assistant will happily walk from a payment into a fraud alert that the person asking was never allowed to see.

I built an open benchmark to measure this: multi-domain enterprise graphs up to 125,000 nodes, role-based permissions, and questions with exactly one correct answer. The results surprised me. Limiting retrieval to the domains a role may see cost no accuracy at all, while an unscoped retriever reached forbidden data on every query. Retrieving by graph community was both less accurate and leaked on 99% of queries. And filtering results after retrieval, the most common fix, still let restricted records decide which answer came first.

You’ll see the benchmark, the numbers, and a simple pattern for Neo4j-backed retrieval: scope before you traverse, keep a shared identity layer, and route only when your router doesn’t miss. Code and data are open.

Rules First, LLMs Last: What 600 Fake Bank Statements Taught Me About AI in Data Pipelines

Everyone wants to put an LLM into their data pipeline. I tested that idea on a hard, practical problem: catching bank statements that were quietly edited to fool a lender. I built an open benchmark of 600 statements and pitted tuned string-matching rules against open-source LLMs. The rules won on accuracy, but they missed almost half of the payee swaps without raising a single alarm. Letting the LLM decide everything was worse. Giving it one narrow job, “is this the same payee?”, cut missed fakes sevenfold. In 15 minutes you’ll see the results, the design pattern that made it work, and a simple rule for deciding where an LLM belongs in your own data pipelines. All code is open and runs for free.

The Payment That Arrived on Thursday: Fixing Training-Serving Skew from Late Events

A customer pays on Monday. The ACH transfer lands on Thursday. On Tuesday, a risk model scores them as someone who hasn’t paid. Months later the model is retrained with hindsight, sees the payment on time, and learns from a world it never saw in production.

Late data isn’t an edge case in financial pipelines; it’s how money moves. Payments clear in one to three days and credit bureau data can take a month. In this session I compare how four common architectures handle it: Lambda, Kappa, a feature store and a classic three-tier medallion. Using an open benchmark of 50,000 synthetic accounts, I show why designs that recover late events create training-serving skew, and why designs that avoid skew drop the late events.

Then I walk through a fix that gets both: train on the exact feature values that were served, correct late events by writing new versions instead of overwriting, and give each event class its own watermark. In the benchmark this removed skew entirely and recovered 100% of late events. I’ll also be honest about what it doesn’t buy you: the accuracy gain was small, and the real wins are audit replay and one less failure mode.

You’ll leave with a checklist for spotting skew in your own pipelines and open-source code to test your architecture against.

Modernizing Legacy ETL Without Breaking the Business: Lessons from Enterprise Migrations

Most legacy ETL estates weren’t designed. They grew over years, one urgent job at a time. In this session I share what I learned leading Ab Initio modernization programs at Discover and Capital One on AWS (EMR, Glue, PySpark): how we inventoried hundreds of jobs, decided what to rebuild and what to retire, and proved the new pipelines matched the old ones before turning anything off. These lessons don’t depend on the platform, and I’ll show how they translate to Fabric. You’ll leave with a practical playbook for running a migration without breaking downstream consumers.

DataRanger: Bridging Distributed Data Pipelines and Agentic Runtimes at Scale

Modern AI agents and autonomous workflows often hit massive scaling and cost walls when attempting to query or ingest real-time distributed data. In this lightning talk, we explore DataRanger, an open-source framework designed to streamline data architecture and execution for high-concurrency systems. We will dive into how unifying distributed streaming patterns with agentic context layers can eliminate processing bottlenecks, reduce cloud compute costs, and ensure reliable data state management across production environments.

Beyond Dashboards: Building AI-Ready Data Platforms with Automated Data Quality and Governance

Reliable business intelligence starts long before data reaches a dashboard. As organizations adopt AI-driven analytics, data quality, lineage, and governance become essential foundations for trustworthy decisions.

This session explores practical architectural patterns for building AI-ready data platforms, including automated quality checks, metadata-driven pipelines, data reconciliation, lineage tracking, and risk-aware remediation.

We'll discuss how these capabilities support reliable Power BI reporting and how emerging agentic approaches can help identify and investigate data quality issues while maintaining human oversight.

Akshay Sharma

Lead Member of Technical Staff, Salesforce | Data & AI Platforms | IEEE Senior Member

Chicago, Illinois, United States

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top