First of all, the BIOS includes a driver for your on-board AHCI controller. And in case the controller is not on-board but on a PCI card, the card will provide a PCI Option ROM containing a BIOS driver for the controller.
If your firmware supports UEFI, it (or the Option ROM) will also include an UEFI driver for the controller.
The same is true for all other components your PC can boot of (i. e. usually USB, CD-ROM, wired network). Other components usually don't have BIOS/UEFI drivers at all.
Operating systems can use the BIOS or UEFI drivers (for example DOS or Windows 95 do so) but most modern operating systems try to avoid the hassle and work around the limitations of the BIOS drivers and instead use their own driver format.
Common limitations of BIOS drivers:
- usually poor read performance and even poorer write performance
- only supported if only the first processor/core is activated
- only work in 16-bit mode (which implies single-tasking and 640KB addressable memory)
- only work if the A20 gate is cleared (which implies 1MB addressable memory)
Which means that during boot, modern OSes will have to repeatedly switch between 16-bit and 32-bit/64-bit single-tasking mode and repeatedly toggle the A20 gate until they have read the OS kernel and at least the disk driver into high memory (640K is usually not enough today); then they will switch to multi-tasking mode and continue loading the rest of the OS using the now loaded kernel and disk driver.
UEFI limitations are less bad (UEFI drivers run in 64-bit mode, but still require single-tasking mode and only one core activated), but still bad enough so that I don't know any OS that tries to use UEFI drivers after boot - and which is probably also the reason nobody wrote a web browser for pure UEFI (web browsers are inherently multi-threaded and it would be hard to write a well-performing single-threaded web-browser).